| From: | Richard Huxton <dev(at)archonet(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Neil Conway <neilc(at)samurai(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: EXPLAIN ANALYZE |
| Date: | 2006-12-11 12:05:37 |
| Message-ID: | 457D4991.7070607@archonet.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Simon Riggs wrote:
> Intermediate results are always better than none at all. I do understand
> what a partial execution would look like - frequently it is the
> preparatory stages that slow a query down - costly sorts, underestimated
> hash joins etc. Other times it is loop underestimation, which can
> usually be seen fairly quickly.
Surely all you're interested in is where the actual plan differs from
the expected plan? Could you not just have a mode that issues NOTICEs
when expected/actual number of rows differ by more than a set amount?
You'd probably want two NOTICEs - one when the threshold is exceeded,
one when the node completes.
--
Richard Huxton
Archonet Ltd
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Takayuki Tsunakawa | 2006-12-11 12:18:26 | Re: Load distributed checkpoint |
| Previous Message | Gregory Stark | 2006-12-11 11:00:02 | Re: EXPLAIN ANALYZE |