X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org
Received: from localhost (mx1.hub.org [200.46.208.251])
	by postgresql.org (Postfix) with ESMTP id 9CBAF9FA2EB
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Thu, 18 May 2006 16:53:26 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024)
	with ESMTP id 68361-07
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Thu, 18 May 2006 16:53:17 -0300 (ADT)
X-Greylist: domain auto-whitelisted by SQLgrey-
Received: from web30709.mail.mud.yahoo.com (web30709.mail.mud.yahoo.com
	[68.142.200.142])
	by postgresql.org (Postfix) with SMTP id 956629F9C18
	for <pgsql-performance@postgresql.org>;
	Thu, 18 May 2006 16:53:17 -0300 (ADT)
Received: (qmail 38329 invoked by uid 60001); 18 May 2006 19:53:16 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=Ue7+aHp0g+tzOyV4pl29OIDVBAves8AKvp4k38TPmkmCdCkUBNJWTtIBzswKQtskjRy2vK3UpeGYVsM45+iVBPO5ih256QOEhLM6MvLWN/7vjvwIQmQyEWqnFf005mDqLJpOI+vuULcqqlX1DnRBmABrJ5vZTTO1oqh9Uv2yJSo=
	;
Message-ID: <20060518195316.38327.qmail@web30709.mail.mud.yahoo.com>
Received: from [206.83.255.230] by web30709.mail.mud.yahoo.com via HTTP;
	Thu, 18 May 2006 12:53:16 PDT
Date: Thu, 18 May 2006 12:53:16 -0700 (PDT)
From: Stephen Byers <stephenabyers@yahoo.com>
Subject: Re: why is bitmap index chosen for this query?
To: "Steinar H. Gunderson" <sgunderson@bigfoot.com>,
	pgsql-performance@postgresql.org
In-Reply-To: <20060518194813.GA8539@uio.no>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1954606787-1147981996=:36047"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200605/398
X-Sequence-Number: 19185

--0-1954606787-1147981996=:36047
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Yes, here are the runtimes for the repeated query.
  Total runtime: 748716.750 ms
Total runtime: 749170.934 ms
Total runtime: 744113.594 ms
Total runtime: 746314.251 ms
Total runtime: 742083.732 ms

  Thanks,
  Steve

"Steinar H. Gunderson" <sgunderson@bigfoot.com> wrote:
  On Thu, May 18, 2006 at 12:38:18PM -0700, Stephen Byers wrote:
> I repeated explain analyze on the query 5 times and it came up with the same plan.

Yes, but did it end up with the same runtime? That's the interesting part --
the plan will almost always be identical between explain analyze runs given
that you haven't done anything in between them.

> You asked about index order and physical table order. In general the index
> order is indeed close to the same order as the physical table order.
> However, this query is likely an exception. The data is actually from a
> backup server that has filled a hole for some of the time range that I'm
> specifying in my query.

Well, it still isn't all that far-fetched to believe that the data has lots
of correlation (which helps the index scan quite a lot) that the planner
isn't able to pick up. I don't know the details here, so I can't tell you how
the correlation for such a query (WHERE a=foo and b between bar and baz) is
estimated. Something tells me someone else might, though. :-)

/* Steinar */
-- 
Homepage: http://www.sesse.net/

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org


			
---------------------------------
Sneak preview the  all-new Yahoo.com. It's not radically different. Just radically better. 
--0-1954606787-1147981996=:36047
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<div>Yes, here are the runtimes for the repeated query.</div>  <div>Total runtime: 748716.750 ms<BR>Total runtime: 749170.934 ms<BR>Total runtime: 744113.594 ms<BR>Total runtime: 746314.251 ms<BR>Total runtime: 742083.732 ms<BR></div>  <div>Thanks,</div>  <div>Steve<BR><BR><B><I>"Steinar H. Gunderson" &lt;sgunderson@bigfoot.com&gt;</I></B> wrote:</div>  <BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">On Thu, May 18, 2006 at 12:38:18PM -0700, Stephen Byers wrote:<BR>&gt; I repeated explain analyze on the query 5 times and it came up with the same plan.<BR><BR>Yes, but did it end up with the same runtime? That's the interesting part --<BR>the plan will almost always be identical between explain analyze runs given<BR>that you haven't done anything in between them.<BR><BR>&gt; You asked about index order and physical table order. In general the index<BR>&gt; order is indeed close to the same order as the physical table
 order.<BR>&gt; However, this query is likely an exception. The data is actually from a<BR>&gt; backup server that has filled a hole for some of the time range that I'm<BR>&gt; specifying in my query.<BR><BR>Well, it still isn't all that far-fetched to believe that the data has lots<BR>of correlation (which helps the index scan quite a lot) that the planner<BR>isn't able to pick up. I don't know the details here, so I can't tell you how<BR>the correlation for such a query (WHERE a=foo and b between bar and baz) is<BR>estimated. Something tells me someone else might, though. :-)<BR><BR>/* Steinar */<BR>-- <BR>Homepage: http://www.sesse.net/<BR><BR>---------------------------(end of broadcast)---------------------------<BR>TIP 4: Have you searched our list archives?<BR><BR>http://archives.postgresql.org<BR></BLOCKQUOTE><BR><p>
	
		<hr size=1>Sneak preview the <a href="http://us.rd.yahoo.com/evt=40762/*http://www.yahoo.com/preview"> all-new Yahoo.com</a>. It's not radically different. Just radically better. 

--0-1954606787-1147981996=:36047--