From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 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-07 12:39:41 |
Message-ID: | 1149683981.2621.614.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2006-06-06 at 16:50 -0400, Tom Lane wrote:
> I have a theory about this, and it's not pleasant at all. What I
> think is that we have a Heisenberg problem here: the act of invoking
> gettimeofday() actually changes what is measured.
> If this theory is correct, then the entire notion of EXPLAIN ANALYZE
> sampling has just crashed and burned. We can't ship a measurement
> tool that is accurate on some platforms and not others.
Regrettably, I would agree and so conclude that we shouldn't pursue the
sampling idea further. Heisenbugs suck time like no other. Interesting,
though.
That leaves us with a number of possibilities:
0. Do Nothing
1. Option to skip timing altogether on an EXPLAIN ANALYZE
2. Option to produce a partial execution only, to locate problem areas.
Any others?
Option 2 would be harder to interpret, but still useful - originally
discussed in a current thread on -perform.
Option 1 wouldn't be as useful as the original sampling idea, but if its
not on the table any longer....
I'd revert back to Option 1 as being the best choice for further work.
Do we agree the idea can't go further? What next?
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-06-07 12:57:50 | Re: How to avoid transaction ID wrap |
Previous Message | Alvaro Herrera | 2006-06-07 12:15:12 | Re: How to avoid transaction ID wrap |