"Kevin Grittner" <kevin.gritt...@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" 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 (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers