From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
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:56:28 |
Message-ID: | 10039.1149864988@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> I propose we revert the sampling patch (sorry Martijn)
yah ...
> and go with the
> patch to have an explain_analyze_timing parameter (default=on).
This I'm unexcited about. EXPLAIN output isn't all that transparent
anyway, and losing the extra cue of seeing where the time is really
going would make it extremely easy for people to misinterpret their
problems.
I was intending to push forward with the idea of being able to get
numbers out of a canceled EXPLAIN. That will allow you to get some
information even when the underlying query runs longer than you're
willing to tolerate. I still say that the number of queries where
avoiding gettimeofday overhead would transform an intolerable runtime
into a tolerable one is pretty limited.
The other thing that I think would be worth investigating is
timer-driven sampling, although it's not yet clear whether we can
make that work usefully. Anyone want to take up that project?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-06-09 15:18:00 | Re: That EXPLAIN ANALYZE patch still needs work |
Previous Message | A.M. | 2006-06-09 14:37:03 | Re: Fabian Pascal and RDBMS deficiencies in fully |