| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Larry Rosenman <ler(at)lerctr(dot)org>, 'Alvaro Herrera' <alvherre(at)commandprompt(dot)com>, 'Martijn van Oosterhout' <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: That EXPLAIN ANALYZE patch still needs work |
| Date: | 2006-06-09 14:31:21 |
| Message-ID: | 1149863481.2691.262.camel@localhost.localdomain |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2006-06-09 at 10:00 -0400, Tom Lane wrote:
> I think the bottom line here is that there are some machines out there
> where gettimeofday() is fast enough for our purposes, and some where
> it is nowhere near fast enough. And that kernel-level fixes may be
> possible for some of the latter, but not all, and we shouldn't hold our
> breath waiting for that to happen anyway.
Agreed.
The issue seems to be some systems are set to get exactly correct times
and some are set to return a time (possibly imprecise) with low
overhead. Even if fixes existed, OS packagers may not pick the right one
of those two options for our purposes for EA. (We might prefer accuracy
to speed for other parts of PostgreSQL anyway).
I propose we revert the sampling patch (sorry Martijn) and go with the
patch to have an explain_analyze_timing parameter (default=on). That way
we'll have an option to turn off timing *if* we happen to be running on
a OS/hw combo that sucks *and* trying to run large enough EAs that we
care.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Cave-Ayland | 2006-06-09 14:36:52 | Re: Proposal for debugging of server-side stored procedures |
| Previous Message | Teodor Sigaev | 2006-06-09 14:27:41 | Re: Snowball and ispell in tsearch2 |