| From: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: Design notes for EquivalenceClasses | 
| Date: | 2007-01-18 00:53:13 | 
| Message-ID: | Pine.LNX.4.58.0701181149190.26830@linuxworld.com.au | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Wed, 17 Jan 2007, Tom Lane wrote:
> Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> writes:
> > I was thinking about this, but in relation to hash joins. A hash join
> > cannot be guaranteed to produce output sorted according to the pathkey of
> > the outer relation (as explained in the existing README). I wonder,
> > however, if it might be useful for hash join to pass a hint that the
> > output is known ordered (i.e., the join was not split into multiple
> > batches).
>
> Yeah, I've considered that, but I think it'd have to be the other way
> around: the planner tells the executor that it's assuming the output is
> sorted, hence do not split into multiple batches.  This has the usual
> assortment of problems if the planner has badly misestimated the
> rowcount :-(
Yep, I thought of that and discarded it for the reason you state.
I still think there would be some benefit to passing a hint up the
execution tree, effectively turning explicit sorts into no ops. This,
however, breaks the major rule in the executor: do what ever the plan
tells you to do.
Thanks,
Gavin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Takayuki Tsunakawa | 2007-01-18 02:09:53 | Re: Idea for fixing the Windows fsync problem | 
| Previous Message | Tom Lane | 2007-01-18 00:50:31 | Re: Function execution costs 'n all that |