Re: Planner regression in 9.1: min(x) cannot use partial index with NOT NULL

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Robert Haas  wrote:
>> Tom Lane  wrote:
>>> I don't think that suppressing nulls from an index this way is
>>> really very useful. Using a partial index probably eats more
>>> planner cycles than you'll save, overall.

>> If only 1% of the table has non-NULL values in that column, maybe
>> not.
> We definitely have indexes with less than 1% non-NULL, and we've
> found partial indexes to be efficient for them.  On the other hand,
> I can't think where we do min/max on any of them; so as long as this
> regression only affects those aggregates, it won't hurt our shop.
> The use case doesn't seem all that far-fetched to me, though.

Hmm.  We could possibly fix this by having planagg.c do a completely
separate planner run for each aggregate, wherein it actually does build
the "equivalent" querySELECT col FROM tab WHERE existing-quals AND col IS NOT NULLORDER BY col ASC/DESC LIMIT 1
and plan that.  That'd be less efficient than the current way,
especially for cases where there are multiple aggregates, because there
would be some duplication of processing between the per-aggregate
planner runs and the main one.  But since we can only do this
optimization for rather simple queries anyway, maybe it wouldn't matter
much.
        regards, tom lane