Re: Explain analyze time overhead

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: salah jubeh <s_jubeh(at)yahoo(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Explain analyze time overhead
Date: 2013-12-05 14:22:14
Message-ID: 14363.1386253334@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

salah jubeh <s_jubeh(at)yahoo(dot)com> writes:
> When I excute a query, the exection time is about 1 minute; however, when I execute the query with explain analyze the excution time jumps to 10 minutes.

This isn't exactly unheard of, although it sounds like you have a
particularly bad case. Cheap commodity PCs tend to have clock hardware
that takes multiple microseconds to read ... which was fine thirty years
ago when that hardware design was set, but with modern CPUs that's
painfully slow.

Short of getting a better machine, you might look into whether you can run
a 64-bit instead of 32-bit operating system. In some cases that allows
a clock reading to happen without a context switch to the kernel.

> This is a little bit starnge for me; did any one experience somthing like this? Can I trust the generated plans?

The numbers are fine as far as they go, but you should realize that the
relative cost of the cheaper plan nodes is being overstated, since the
added instrumentation cost is the same per node call regardless of how
much work happens within the node.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message bricklen 2013-12-05 14:28:41 Re: One huge db vs many small dbs
Previous Message vincent elschot 2013-12-05 14:21:20 Re: Explain analyze time overhead