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

From: Achilleas Mantzios <achill(at)matrix(dot)gatewaynet(dot)com>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: Postgresql 9.0.2 explain analyze very slow (10x), compared to actual query time
Date: 2011-01-12 16:17:10
Message-ID: 201101121817.11143.achill@matrix.gatewaynet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Στις Wednesday 12 January 2011 17:07:53 ο/η Tom Lane έγραψε:
> Achilleas Mantzios <achill(at)matrix(dot)gatewaynet(dot)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 optimization is 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.id AND 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

Attachment Content-Type Size
2tom_linuxprod_query_plan.txt text/plain 4.5 KB
2tom_fbsdtest_query_plan.txt text/plain 4.9 KB

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2011-01-12 16:45:20 Re: Postgresql 9.0.2 explain analyze very slow (10x), compared to actual query time
Previous Message Tom Lane 2011-01-12 15:07:53 Re: Postgresql 9.0.2 explain analyze very slow (10x), compared to actual query time