Noah Misch <n...@leadboat.com> writes:
> If the attached patch version looks reasonable, I will commit it.
The test case is completely bogus, as the query explained is significantly
different from the query executed. I'm not sure whether you can just
remove the extra ORDER BY column without getting machine-dependent
results, though.
More generally, I'm afraid the whole approach is probably wrong, or at
least not solving all problems in this area, because of this:
> Incidentally, I tried adding an assertion that append_rel_list does not show
> one appendrel as a direct child of another. The following query, off-topic
> for the patch at hand, triggered that assertion:
> SELECT 0 FROM (SELECT 0 UNION ALL SELECT 0) t0
> UNION ALL
> SELECT 0 FROM (SELECT 0 UNION ALL SELECT 0) t0;
That's not "off topic" at all; it shows that there's not been any effort
to date to flatten appendrel membership, and therefore this partial
implementation is going to miss some cases. It doesn't help to merge an
inheritance-based appendrel into its parent if the query ORDER BY is still
a level or two above that due to UNION ALLs.
I wonder whether we should consider adding a pass to flatten any nested
appendrels after we're done creating them all. Or alternatively, perhaps
rather than changing the representation invariant, we need to take a
harder look at why ordering info isn't getting pushed down through
appendrels.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
