Re: unnesesary sorting after Merge Full Join

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "Alexey A(dot) Nalbat" <nalbat(at)price(dot)ru>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Decibel!" <decibel(at)decibel(dot)org>, pgsql-general(at)postgresql(dot)org
Subject: Re: unnesesary sorting after Merge Full Join
Date: 2008-02-26 17:18:43
Message-ID: 4458.1204046323@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I wrote:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> as a path key, though we would have to create an equivalence class
>> and add COALESCE(id2,id1) to it as well I think.

> No, because those two expressions are not equivalent. (Hmm ... squint
> ... but full merge join is pretty much symmetric, so it's not clear
> why it should matter which side is left or right. Maybe COALESCE isn't
> exactly the right concept with which to describe the merged variable?)

Wait ... after consuming more caffeine, I think you were right. The
point of an EquivalenceClass is that it asserts the contained
expressions must have the same values, and in the case of a full join
it actually is the case that COALESCE(id1,id2) = COALESCE(id2,id1)
at every output row. So it's legitimate to put both expressions in
the same eclass, even though their values might be different in other
circumstances. And that solves our symmetry problem because the eclass
is the same whichever way you build it.

It might still be interesting sometime to have a more bespoke
representation for a merged variable, but I guess we don't need
it just for this.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Gregory Stark 2008-02-26 17:26:34 Re: Query meltdown: caching results
Previous Message Richard Huxton 2008-02-26 17:08:27 Re: how to auto GRANT custom ACL on a new table?