Re: Can the V7.3 EXPLAIN ANALYZE be trusted?

From: Markus Schaber <schabios(at)logi-track(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Cc: Steven Rosenstein <srosenst(at)us(dot)ibm(dot)com>
Subject: Re: Can the V7.3 EXPLAIN ANALYZE be trusted?
Date: 2005-02-07 14:39:15
Message-ID: 42077D93.4000104@logi-track.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hi, @all,

Greg Stark schrieb:
> "Leeuw van der, Tim" <tim(dot)leeuwvander(at)nl(dot)unisys(dot)com> writes:
>
>>I don't think EXPLAIN ANALYZE puts that much overhead on a query.
>
> EXPLAIN ANALYZE does indeed impose a significant overhead.

Additional note:

In some rare cases, you can experience just the opposite effect, explain
analyze can be quicker then the actual query.

This is the case for rather expensive send/output functions, like the
PostGIS ones:

lwgeom=# \timing
Zeitmessung ist an.
lwgeom=# explain analyze select setsrid(geom,4326) from adminbndy1;
QUERY PLAN

-----------------------------------------------------------------------------------------------------------
Seq Scan on adminbndy1 (cost=0.00..4.04 rows=83 width=89) (actual
time=11.793..2170.184 rows=83 loops=1)
Total runtime: 2170.834 ms
(2 Zeilen)

Zeit: 2171,688 ms
lwgeom=# \o /dev/null
lwgeom=# select setsrid(geom,4326) from adminbndy1;
Zeit: 9681,001 ms

BTW: I use the cheap setsrid(geom,4326) to force deTOASTing of the
geometry column. Not using it seems to ignore TOASTed columns in
sequential scan simulation.)

lwgeom=# explain analyze select geom from adminbndy1;
QUERY PLAN

-------------------------------------------------------------------------------------------------------
Seq Scan on adminbndy1 (cost=0.00..3.83 rows=83 width=89) (actual
time=0.089..0.499 rows=83 loops=1)
Total runtime: 0.820 ms
(2 Zeilen)

Markus

--
markus schaber | dipl. informatiker
logi-track ag | rennweg 14-16 | ch 8001 zürich
phone +41-43-888 62 52 | fax +41-43-888 62 53
mailto:schabios(at)logi-track(dot)com | www.logi-track.com

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Joost Kraaijeveld 2005-02-07 16:37:53 Retry: Is this possible / slow performance?
Previous Message Markus Schaber 2005-02-07 14:07:44 Re: Bad query optimizer misestimation because of TOAST