From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Simon Riggs <simon@2ndquadrant.com>, Jeff Janes <jeff.janes@gmail.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [PERFORM] Slow query: bitmap scan troubles
In-reply-to: 
 <CA+Tgmoa+wzu9RBUK75veRn6UTWjSZZJa2aOjfvn0LD1_mx+rRg@mail.gmail.com>
References: <092a01cdd230$ff6143c0$fe23cb40$@foo.me.uk>
	<CAGTBQpaKOfZs+qy+S7CCPcTg7PYOrwgcQAXgWV88cQTn-BFstg@mail.gmail.com>
	<CAMkU=1wEc1cCeUdR1oZ3Q2fe2pGj6tvrwRcY2obbfEk8LcNypQ@mail.gmail.com>
	<097601cdd249$ae338530$0a9a8f90$@foo.me.uk>
	<CAMkU=1wmxKifgUufbSffQ+VH3kFNczK65MxXetwVFJZd3zvkeA@mail.gmail.com>
	<CAMkU=1w40aQt0twukCsvL2hPHUPujLqJBe8v90phuqBJ5wgw1Q@mail.gmail.com>
	<9022.1354730710@sss.pgh.pa.us>
	<CAMkU=1ykyMgXccv2dAWKOXdDx5U0Qpc28aW6k659hvE7VZEMXQ@mail.gmail.com>
	<28944.1357424296@sss.pgh.pa.us>
	<CA+U5nMLJBrnU+B6md5VR1GHGz6Ji5MEZd6QE+favQYLjv9H8JA@mail.gmail.com>
	<18164.1357498720@sss.pgh.pa.us>
	<CA+U5nMLjf2-kTa4-AR-0XLKKwbc+=_fb4237i_UAWYzowW+-1Q@mail.gmail.com>
	<8539.1357513385@sss.pgh.pa.us> <12791.1357580151@sss.pgh.pa.us>
	<CA+U5nMKbOGVfQXfJi5_vOUPEatF_V_+e_HX4P5R=tb9JSo2ceA@mail.gmail.com>
	<13842.1357583258@sss.pgh.pa.us> <13967.1357866454@sss.pgh.pa.us>
	<CA+TgmoYQ6Nq-tpHiDPCUH3CkH2N9D67=oDKJtLxuRRC=dRteSQ@mail.gmail.com>
	<23869.1358184197@sss.pgh.pa.us> <CA+Tg!
	moa+wzu9RBUK75veRn6UTWjSZZJa2aOjfvn0LD1_mx+rRg@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Mon, 14 Jan 2013 12:50:24 -0500"
Date: Mon, 14 Jan 2013 12:56:37 -0500
Message-ID: <24605.1358186197@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jan 14, 2013 at 12:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

Remember also that "enable_seqscan=off" merely adds 1e10 to the
estimated cost of seqscans.  For sufficiently large tables this is not
exactly a hard disable, just a thumb on the scales.  But I don't know
what your definition of "extremely large indexes" is.

			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