From: Achilleas Mantzios <achill@matrix.gatewaynet.com>
Organization: Dynacom Tankers Mgmt
To: pgsql-admin@postgresql.org
Subject: Re: Postgresql 9.0.2 explain analyze very slow (10x),
	compared to actual query time
Date: Thu, 13 Jan 2011 12:35:12 +0200
User-Agent: KMail/1.9.7
References: <201101111753.22602.achill@matrix.gatewaynet.com>
	<27365.1294850720@sss.pgh.pa.us> <op.vo7gzdoo34t2sn@tech304>
In-Reply-To: <op.vo7gzdoo34t2sn@tech304>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-7"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <201101131235.13107.achill@matrix.gatewaynet.com>

=D3=F4=E9=F2 Wednesday 12 January 2011 19:17:28 =EF/=E7 Mark Felder =DD=E3=
=F1=E1=F8=E5:
> On Wed, 12 Jan 2011 10:45:20 -0600, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > The short of it is that cheap motherboards tend to provide cheap clock=
=20
> > hardware that takes about a microsecond to read.
>=20
> I'm not sure how gettimeofday() works, but is there a slight chance this =
=20
> could be alleviated by choosing a different kern.timecounter.hardware =20
> option?
>=20
> kern.timecounter.choice: TSC(800) HPET(900) ACPI-fast(1000) i8254(0) =20
> dummy(-1000000)
> kern.timecounter.hardware: ACPI-fast
>=20
> Or does the kernel timer stuff have nothing to do with gettimeofday()?
Thanx,
Actually setting sysctl kern.timecounter.hardware=3DTSC
and making the program look like: (increased the loop from 1,000,000 to 100=
,000,000)

#include <stdio.h>
#include <stdlib.h>
#include <sys/time.h>
int main(int argc,char** argv) {
        struct timeval *tp=3Dcalloc(1,sizeof(struct timeval));
        int runna;
        double micros_total=3D0;
        for (runna=3D0;runna<100000000;runna++) {
                int rc=3Dgettimeofday(tp,NULL);
                long micros =3D tp->tv_sec * 1000000 + tp->tv_usec;
                micros_total =3D micros_total + (double) micros;
        }
        printf("micros_total=3D%f\n",micros_total);
}

I get in LINUX_PROD
time ./gettimeofday_test
micros_total=3D129491418242412709937152.000000

real    0m16.665s
user    0m16.621s
sys     0m0.000s

and in FBSD_TEST
time ./gettimeofday_test
micros_total=3D129491437864563859521536.000000

real    0m15.506s
user    0m0.517s
sys     0m1.161s

So, the FBSD_TEST case although still involves some kernel overhead, it is =
faster than LINUX_PROD
(but i am puzzled as to where those 15.5 secs come from since 1.16+
>=20
>=20
> Regards,
>=20
>=20
> Mark
>=20


=2D-=20
Achilleas Mantzios