2010/9/28 Robert Haas <robertmh...@gmail.com>: > 2010/9/23 Robert Haas <robertmh...@gmail.com>: >> All of this leaves me wondering why Greg ended up ifdefing out this >> code in the first place. There's probably something I'm missing >> here... but for now I can't think of a better idea than just removing >> the #ifdefs and hoping that whatever problem they were causing was >> limited to an earlier version of the code that no longer exists. > > ...and FAIL. I missed the blindingly obvious here, which is that > without these tests commented out, while it passes regression tests, > the merge append stuff stops working. I think for some reason without > this stuff in there the appropriate index paths fail to get generated > for the child rels.
Yep, that's the problem, all right. find_usable_indexes() calls build_index_pathkeys() to generate pathkeys for each available index on the child relation, and then calls truncate_useless_pathkeys() to get rid of any that aren't useful. In a query like this: explain select * from ma_parent order by name limit 10; ...what makes the pathkeys potentially useful is that they match the root pathkeys for the query. However, without Greg's hacks, the transposed child equivalence classes don't show up in the equivalence member lists, so get_eclass_for_sort_expr() generates new equivalence classes for them. Subsequently, when truncate_useless_pathkeys() is called, those new equivalence classes are found not to be equal to the overall ordering desired for the query, so it truncates them away. I'm not presently sure quite what the best way to fix this is... any ideas? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers