Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TvCqm-00061r-Aw for pgsql-hackers@arkaria.postgresql.org; Tue, 15 Jan 2013 20:11:12 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1TvCql-00088n-Ns for pgsql-hackers@arkaria.postgresql.org; Tue, 15 Jan 2013 20:11:11 +0000 Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TvCqj-00087M-NX for pgsql-hackers@postgresql.org; Tue, 15 Jan 2013 20:11:09 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TvCqf-0005ve-W6 for pgsql-hackers@postgresql.org; Tue, 15 Jan 2013 20:11:09 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id r0FKB2UL001724; Tue, 15 Jan 2013 15:11:03 -0500 (EST) From: Tom Lane To: Bruce Momjian cc: Robert Haas , Simon Riggs , Jeff Janes , pgsql-hackers Subject: Re: [PERFORM] Slow query: bitmap scan troubles In-reply-to: <20130115194639.GG27934@momjian.us> References: <8539.1357513385@sss.pgh.pa.us> <12791.1357580151@sss.pgh.pa.us> <13842.1357583258@sss.pgh.pa.us> <13967.1357866454@sss.pgh.pa.us> <23869.1358184197@sss.pgh.pa.us> <24605.1358186197@sss.pgh.pa.us> <20130115194639.GG27934@momjian.us> Comments: In-reply-to Bruce Momjian message dated "Tue, 15 Jan 2013 14:46:39 -0500" Date: Tue, 15 Jan 2013 15:11:02 -0500 Message-ID: <1723.1358280662@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Bruce Momjian writes: > On Mon, Jan 14, 2013 at 12:56:37PM -0500, Tom Lane wrote: >> 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. > Wow, do we need to bump up that value based on larger modern hardware? I'm disinclined to bump it up very much. If it's more than about 1e16, ordinary cost contributions would disappear into float8 roundoff error, causing the planner to be making choices that are utterly random except for minimizing the number of seqscans. Even at 1e14 or so you'd be losing a lot of finer-grain distinctions. What we want is for the behavior to be "minimize the number of seqscans but plan normally otherwise", so those other cost contributions are still important. Anyway, at this point we're merely speculating about what's behind Robert's report --- I'd want to see some concrete real-world examples before changing anything. 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