To: Achilleas Mantzios <achill@matrix.gatewaynet.com>
cc: pgsql-admin@postgresql.org
Subject: Re: Postgresql 9.0.2 explain analyze very slow (10x),
	compared to actual query time
In-reply-to: <201101121318.44007.achill@matrix.gatewaynet.com> 
References: <201101111753.22602.achill@matrix.gatewaynet.com>
	<18991.1294762751@sss.pgh.pa.us>
	<201101121318.44007.achill@matrix.gatewaynet.com>
Comments: In-reply-to Achilleas Mantzios <achill@matrix.gatewaynet.com>
	message dated "Wed, 12 Jan 2011 13:18:43 +0200"
Date: Wed, 12 Jan 2011 10:07:53 -0500
Message-ID: <25677.1294844873@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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.

> 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 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?

			regards, tom lane