Re: Path question

2010/9/28 Robert Haas <robertmhaas(at)gmail(dot)com>:
> 2010/9/23 Robert Haas <robertmhaas(at)gmail(dot)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