Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> 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.
> It might have an advantage if you're doing a three-way outer
"Tom Lane" <[EMAIL PROTECTED]> writes:
> I wrote:
>> Gregory Stark <[EMAIL PROTECTED]> 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
>>
I wrote:
> Gregory Stark <[EMAIL PROTECTED]> 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
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Tue, 2008-02-26 at 10:34 -0500, Tom Lane wrote:
> 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
On Tue, 2008-02-26 at 10:34 -0500, Tom Lane wrote:
> > 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 righ
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Alexey A. Nalbat" <[EMAIL PROTECTED]> writes:
>> Yes. But may be the FULL MERGE JOIN could be improved, because it
>> is ordered, it actually has "outer path's path key": "coalesce(id1,id2)".
No, it does not have the outer path's path key. The outer pa
"Alexey A. Nalbat" <[EMAIL PROTECTED]> writes:
> Yes. But may be the FULL MERGE JOIN could be improved, because it
> is ordered, it actually has "outer path's path key": "coalesce(id1,id2)".
Hm, there's more going on here than meets the eye. If you changed the query
slightly Postgres would actua
> I found comment in src/backend/optimizer/path/pathkeys.c:
> * EXCEPTION: in a FULL or RIGHT join, we cannot treat the result as
> * having the outer path's path keys, because null lefthand rows may be
> * inserted at random points. It must be treated as unsorted.
>
> How can I get rid of this so
On Sat, 2008-02-23 at 14:49 -0600, Decibel! wrote:
> On Feb 21, 2008, at 4:08 AM, Alexey Nalbat wrote:
> > I found comment in src/backend/optimizer/path/pathkeys.c:
> > * EXCEPTION: in a FULL or RIGHT join, we cannot treat the result as
> > * having the outer path's path keys, because null lefthan
On Feb 21, 2008, at 4:08 AM, Alexey Nalbat wrote:
I'd like to use ORDER BY in any specified order and LIMIT, OFFSET
for paging query results.
The query is FULL OUTER JOIN of two tables by field id. I think the
results of Merge Full Join
to be ordered by some "combined id". And there is no need
Hello.
I'd like to use ORDER BY in any specified order and LIMIT, OFFSET for paging
query results.
The query is FULL OUTER JOIN of two tables by field id. I think the results of
Merge Full Join
to be ordered by some "combined id". And there is no need in extra Sort if I
specify ORDER BY
that "c
11 matches
Mail list logo
