| From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | "Gavin Sherry" <swm(at)linuxworld(dot)com(dot)au> |
| Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Design notes for EquivalenceClasses |
| Date: | 2007-01-18 11:36:53 |
| Message-ID: | 1169120213.3927.83.camel@silverbirch.site |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 2007-01-18 at 11:53 +1100, Gavin Sherry wrote:
> the major rule in the executor: do what ever the plan tells you to do.
I thought the rule was: do what the plan tells you to do, as efficiently
as possible.
Turning an explicit step into a no-op seems like great execution to me.
In the case you mention, the HashJoin node already looks inside its Hash
node child. It seems possible to have the Sort node check at ExecInit
time that it is sitting on a HashJoin node, so that at Exec time it can
ask the HashJoin node whether the Hash node has spilled to disk or not.
If not, it can just pass the rows through as a no-op.
We could formalise a "last words" API so that parent nodes sometimes
calls child nodes before they execute them, or maybe just leave it
somewhat dirty as the H/HJ communication is now.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuo Ishii | 2007-01-18 13:49:53 | Re: pgsql: Fix failure due to accessing an |
| Previous Message | korryd | 2007-01-18 10:57:14 | Re: Scanner/Parser question - what does _P imply? |