Skip site navigation (1) Skip section navigation (2)

Re: Append nodes and orderings

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Append nodes and orderings
Date: 2007-10-27 13:55:44
Message-ID: 15979.1193493344@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> This requires treating columns of subrels as equivalent to the columns of the
> parent. Offhand I think that's theoretically ok since they'll never be
> available except where they are in fact equivalent, but I'm not too familiar
> with equivalence classes. There are a few comments indicating we don't
> currently fully track columns of subrels of append rels in equivalence
> classes. I'm not sure what the consequences of adding those columns as full
> members of the equivalence classes would be.

I don't think they're really equivalent in that sense.  The implication
of putting A and B in the same equivalence class is "if it's sorted by
A, it can also be considered sorted by B, and vice versa".  This is
clearly not the case for an append variable and a member variable ---
their relationship is asymmetric.

I think you probably want to think in terms of converting the outer
pathkeys (mentioning the append variable) into pathkeys that mention
the member variables, and then seeing if you can get a subpath that's
sorted that way.  Compare the handling of sub-select ordering.  (Not
that that's really clean :-()

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Gregory StarkDate: 2007-10-27 13:57:01
Subject: Re: Proposal: real procedures again (8.4)
Previous:From: Tom LaneDate: 2007-10-27 13:46:03
Subject: Re: min/max planner optimization

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group