| From: | Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com> |
|---|---|
| To: | Filip Rembiałkowski <plk(dot)zuber(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Szymon Guz <mabewlun(at)gmail(dot)com>, PostgreSQL <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: strange |
| Date: | 2010-03-23 12:12:33 |
| Message-ID: | 2f4958ff1003230512k626f2799sb01371675dc4ae44@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
2010/3/23 Filip Rembiałkowski <plk(dot)zuber(at)gmail(dot)com>
> 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?
>
>
>
Apparently you can force linux kernel to consider different time source, as
it sort of guess-probes which one would be the best when it boots.
I don't remember the exact option, but it is easy to find on the net.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Mead | 2010-03-23 12:12:51 | Re: Before triggers and usage in partitioned tables |
| Previous Message | Filip Rembiałkowski | 2010-03-23 11:48:25 | Re: strange |