pg.ddx.io  pgsql-admin@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Achilleas Mantzios <achill@matrix.gatewaynet.com>
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
Message-ID: <201101131235.13107.achill@matrix.gatewaynet.com> (raw)
In-Reply-To: <op.vo7gzdoo34t2sn@tech304>
References: <201101111753.22602.achill@matrix.gatewaynet.com>
	<27365.1294850720@sss.pgh.pa.us>
	<op.vo7gzdoo34t2sn@tech304>

Óôéò Wednesday 12 January 2011 19:17:28 ï/ç Mark Felder Ýãñáøå:
> 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 
> > hardware that takes about a microsecond to read.
> 
> I'm not sure how gettimeofday() works, but is there a slight chance this  
> could be alleviated by choosing a different kern.timecounter.hardware  
> option?
> 
> kern.timecounter.choice: TSC(800) HPET(900) ACPI-fast(1000) i8254(0)  
> dummy(-1000000)
> kern.timecounter.hardware: ACPI-fast
> 
> Or does the kernel timer stuff have nothing to do with gettimeofday()?
Thanx,
Actually setting sysctl kern.timecounter.hardware=TSC
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=calloc(1,sizeof(struct timeval));
        int runna;
        double micros_total=0;
        for (runna=0;runna<100000000;runna++) {
                int rc=gettimeofday(tp,NULL);
                long micros = tp->tv_sec * 1000000 + tp->tv_usec;
                micros_total = micros_total + (double) micros;
        }
        printf("micros_total=%f\n",micros_total);
}

I get in LINUX_PROD
time ./gettimeofday_test
micros_total=129491418242412709937152.000000

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

and in FBSD_TEST
time ./gettimeofday_test
micros_total=129491437864563859521536.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+
> 
> 
> Regards,
> 
> 
> Mark
> 



-- 
Achilleas Mantzios



view thread (25+ messages)  latest in thread

Message-ID: <201101131235.13107.achill@matrix.gatewaynet.com>
Permalink:  ../201101131235.13107.achill@matrix.gatewaynet.com/
Also on:    postgresql.org/message-id/201101131235.13107.achill@matrix.gatewaynet.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-admin@postgresql.org
  Cc: achill@matrix.gatewaynet.com
  Subject: Re: Postgresql 9.0.2 explain analyze very slow (10x), compared to actual query time
  In-Reply-To: <201101131235.13107.achill@matrix.gatewaynet.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox