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

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)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" query
SELECT col FROM tab WHERE existing-quals AND col IS NOT NULL
ORDER 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