| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Filip Rembiałkowski <plk(dot)zuber(at)gmail(dot)com> |
| Cc: | Szymon Guz <mabewlun(at)gmail(dot)com>, PostgreSQL <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: strange |
| Date: | 2010-03-23 15:49:00 |
| Message-ID: | 28989.1269359340@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
=?UTF-8?Q?Filip_Rembia=C5=82kowski?= <plk(dot)zuber(at)gmail(dot)com> writes:
> For the record, I've recently observed such behaviour on non-cheap
> 64bit server harware.
> That was Pg 8.4.0. hardware specs available on request.
> EXPLAIN ANALYZE SELECT was over 2 times slower that SELECT. repeatedly.
> Answering an obligatory question: NO virtualization (vmware/xen/other) there.
> Question:
> Is there anything as normal, accepted level of performance degradation
> when using EXPLAIN ANALYZE compared to plain query?
You should certainly not expect it to be free, if that's what you mean.
2X penalty on a very cheap plan node (such as a seqscan with no filter)
doesn't surprise me much.
BTW, it occurs to me that gettimeofday's microsecond resolution doesn't
really get the job done anymore for such cheap plan nodes. I wonder if
we should be trying to use clock_gettime() where available.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ben Chobot | 2010-03-23 16:25:49 | [SPAM] Re: pgreplay log file replayer released |
| Previous Message | Tom Lane | 2010-03-23 15:33:33 | Re: PL/pgSQL & OVERLAPS operator |