Skip site navigation (1) Skip section navigation (2)

Re: [PERFORM] Slow query: bitmap scan troubles

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PERFORM] Slow query: bitmap scan troubles
Date: 2013-01-14 17:50:24
Message-ID: CA+Tgmoa+wzu9RBUK75veRn6UTWjSZZJa2aOjfvn0LD1_mx+rRg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
On Mon, Jan 14, 2013 at 12:23 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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.1357866454@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


In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2013-01-14 17:56:37
Subject: Re: [PERFORM] Slow query: bitmap scan troubles
Previous:From: Tom LaneDate: 2013-01-14 17:23:17
Subject: Re: [PERFORM] Slow query: bitmap scan troubles

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2013-01-14 17:52:11
Subject: Re: json api WIP patch
Previous:From: Casey Allen ShobeDate: 2013-01-14 17:49:32
Subject: Re: Privileges for INFORMATION_SCHEMA.SCHEMATA (was Re: Small clarification in "34.41. schemata")

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group