Re: Postgresql 9.0.2 explain analyze very slow (10x), compared to actual query time

Στις Wednesday 12 January 2011 17:07:53 ο/η Tom Lane έγραψε:
> Achilleas Mantzios <achill@matrix.gatewaynet.com> writes:
> > Regarding gettimeofday (2), i wrote this program :
> > #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;
> >         for (runna=0;runna<1000000;runna++) {
> >                 int rc=gettimeofday(tp,NULL);
> >                 long micros = tp->tv_sec * 1000000 + tp->tv_usec;
> >                 printf("cur_time=%u micro secs\n",micros);
> >         }
> > }
>
> Right offhand I'd wonder whether that was more bound by gettimeofday or
> by printf.  Please try it without printf in the loop.
>

Changed that to smth like: micros_total = micros_total + (double) micros;
instead of the printf to beat any compiler optimization, and still linux runs at light speed:
FBSD_TEST : user 0.089s, sys 1.4s
FBSD_DEV : user 0.183s, sys 3.8s
LINUX_PROD : user 0.168s, sys 0s
(regarding that gettimeofday is a syscall in FreeBSD, and that sys time is 0 for linux, makes me think some
optimizationis being done) 

> > 3) Test machine (thereafter called FBSD_TEST) :
> > System: FreeBSD 8.1, 4 x AMD Phenom(tm) 965 @ 3.4 GHz, 8GB memory
> > DB: PostgreSQL 9.0.2, shared_buffers=5GB, work_mem=512MB, db size=7GB
>
> The shared_buffers setting seems way out of line compared to actual
> memory on this machine.  Maybe it's swapping.
>

I tried with what pgtune suggests (1920MB) and i get same results.
For the simple query: SELECT avg(md.perioddue) from status st,items it,machdefs md WHERE st.id<=3626961 AND
st.apptblidval=it.idAND it.defid=md.defid; 
still FBSD_TEST runs faster than LINUX_PROD smth like (3.5 secs VS 5.8 secs)

> > i get the following execution times: (with \timing) (note however that FBSD_DEV has a considerably smaller
database,the other two are compareable) 
> > FBSD_DEV : query : 240,419 ms, EXPLAIN ANALYZE query : Total runtime: 538.468 ms
> > LINUX_PROD : query : 219.568 ms, EXPLAIN ANALYZE query : Total runtime: 216.926 ms
> > FBSD_TEST : query : 2587,465 ms, EPXLAIN ANALYZE query : Total runtime: 93711.648 ms
> > The last numbers seem huge.
>
> Are they in fact the same query plans in each case?

The query plans seem to differ. A lot of seq scans in the FBSD case.
I attach the query plans for LINUX_PROD, FBSD_TEST (the times did not change noticeably after the new shared_buffers
setting)

>
>             regards, tom lane
>



--
Achilleas Mantzios