On Mon, Jan 14, 2013 at 12:23 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> I'm not sure I have anything intelligent to add to this conversation - >> does that make me the wisest of all the Greeks? - but I do think it >> worth mentioning that I have heard occasional reports within EDB of >> the query planner refusing to use extremely large indexes no matter >> how large a hammer was applied. I have never been able to obtain >> enough details to understand the parameters of the problem, let alone >> reproduce it, but I thought it might be worth mentioning anyway in >> case it's both real and related to the case at hand. Basically I >> guess that boils down to: it would be good to consider whether the >> costing model is correct for an index of, say, 1TB. > > Well, see the cost curves at > http://www.postgresql.org/message-id/13967.1357866...@sss.pgh.pa.us > > The old code definitely had an unreasonably large charge for indexes > exceeding 1e8 or so tuples. This wouldn't matter that much for simple > single-table lookup queries, but I could easily see it putting the > kibosh on uses of an index on the inside of a nestloop.
The reported behavior was that the planner would prefer to sequential-scan the table rather than use the index, even if enable_seqscan=off. I'm not sure what the query looked like, but it could have been something best implemented as a nested loop w/inner index-scan. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
