Robert Haas <robertmh...@gmail.com> wrote: > Right now, our costing model for index-only scans is pretty dumb. > It assumes that using an index-only scan will avoid 10% of the > heap fetches. That could easily be low, and on an insert-only > table or one where only the recently-updated rows are routinely > accessed, it could also be high. As a reality check, I just ran this query on a table in a statewide copy of our data: select count(*), sum(case when xmin = '2'::xid then 0 else 1 end) as read_heap from "CaseHist"; and got: count | read_heap -----------+----------- 205765311 | 3934924 So on our real-world database, it would skip something on the order of 98% of the heap reads, right? > This isn't just an exercise in costing, though: right now, we > don't even generate a plan to use an index for a full-table scan, > because we assume that it can never be cheaper. This is actually > not quite true even in previous releases (suppose the table is > severely bloated but the index is not) and it's going to be less > true now that we have index-only scans. So that's going to need > some adjustment, too. OK. Thanks for clarifying. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
