Tom Lane <[EMAIL PROTECTED]> writes: > Greg Stark <[EMAIL PROTECTED]> writes: > > why isn't a "skip index scan" plan available? Well, nobody's written the code > > yet. > > I don't really think it would be a useful plan anyway.
Well it would clearly be useful in this test case, where has a small number of distinct values in a large table, and an index on the column. His plpgsql function that emulates such a plan is an order of magnitude faster than the hash aggregate plan even though it has to do entirely separate index scans for each key value. I'm not sure where the break-even point would be, but it would probably be pretty low. Probably somewhere around the order of 1% distinct values in the table. That might be uncommon, but certainly not impossible. But regardless of how uncommon it is, it could be considered important in another sense: when you need it there really isn't any alternative. It's an algorithmic improvement with no bound on the performance difference. Nothing short of using a manually maintained materialized view would bring the performance into the same ballpark. So even if it's only useful occasionally, not having the plan available can leave postgres with no effective plan for what should be an easy query. -- greg ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html