"Kevin Grittner" <[email protected]> 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
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
