Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id D9F4C9FB65E for ; Tue, 17 Apr 2007 00:43:34 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 13669-04 for ; Tue, 17 Apr 2007 00:43:25 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4 Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.235]) by postgresql.org (Postfix) with ESMTP id 367A99FB52E for ; Tue, 17 Apr 2007 00:43:31 -0300 (ADT) Received: by nz-out-0506.google.com with SMTP id r28so1398747nza for ; Mon, 16 Apr 2007 20:43:30 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=umVVNqrZx5/epX4/iJh1xhTTGICX2Xi5mfxTfd2r5bWUip1Tyi+0CXVdcrGUp1TrwGTmnbwh2xJEkbmwRGFLXQhVqa7muRJA7C1Ykq9px1YWSf2DiL7DgEsh9vSh5+Gq5H+QsbEajfqQQdkBBoPCZllDhjW5JSBmNlHObpvglcM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=tzUILfgOB2WoIs83dMPLR6c5F7393rJmXWQqDqdafpA/GTwvsfC96bzatCnWQhYdRpQU6mfLBmmWAtb8rfeWVdkeoQcKXvUcIfutn4nE8vA9nbUaLhBUWSa73JHqUzvjtyl1yao8AzeJt2f/NEJQH8rQ8H8wtvtQezCPRtQ6+NM= Received: by 10.114.198.1 with SMTP id v1mr2218791waf.1176781410219; Mon, 16 Apr 2007 20:43:30 -0700 (PDT) Received: by 10.115.107.9 with HTTP; Mon, 16 Apr 2007 20:43:30 -0700 (PDT) Message-ID: <36af4bed0704162043k23e6bde4hf3d9840dc359f010@mail.gmail.com> Date: Tue, 17 Apr 2007 09:13:30 +0530 From: Robins Reply-To: robins@pobox.com To: pgsql-performance@postgresql.org Subject: Fwd: Strangely Variable Query Performance In-Reply-To: <36af4bed0704162024t23f7d6bbnf4b8042b82b16935@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_57014_5493085.1176781410069" References: <57271CC2-BCB1-4ACA-A177-4FF64F1BC33F@brandeis.edu> <10355.1176422445@sss.pgh.pa.us> <10503.1176423606@sss.pgh.pa.us> <12360.1176436194@sss.pgh.pa.us> <12736.1176439091@sss.pgh.pa.us> <36af4bed0704162024t23f7d6bbnf4b8042b82b16935@mail.gmail.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200704/323 X-Sequence-Number: 24200 ------=_Part_57014_5493085.1176781410069 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Tom / Steve, Am one of the silent readers of performance issues that come up on this list (and are discussed in detail) ... just like this one. If and when you do come up with a solution, please do post some details about them here... (i say that coz it seems that for obvious reasons, things must have gone off air after tom's last email, and one can understand that). But an analysis, or atleast a pointer may be of help to someone (like me) reading this list. Thanks Robins ---------- Forwarded message ---------- From: Tom Lane Date: Apr 13, 2007 10:08 AM Subject: Re: [PERFORM] Strangely Variable Query Performance To: Steve Cc: Scott Marlowe , PostgreSQL Performance < pgsql-performance@postgresql.org> Steve writes: > On Thu, 12 Apr 2007, Tom Lane wrote: >> I'm still not having any luck reproducing the failure here. Grasping at >> straws again, I wonder if it's got something to do with the order in >> which the planner examines the indexes --- which is OID order. Could >> you send me the results of > Here you go: Nope, still doesn't fail for me. [ baffled and annoyed... ] There must be something about your situation that's relevant but we aren't recognizing it. Are you in a position to let me ssh into your machine and try to debug it? Or other options like sending me a dump of your database? I'm about out of steam for tonight, but let's talk about it off-list tomorrow. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match ------=_Part_57014_5493085.1176781410069 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Tom / Steve,

Am one of the silent readers of performance issues that come up on this list (and are discussed in detail) ... just like this one.

If and when you do come up with a solution, please do post some details about them here... (i say that coz it seems that for obvious reasons, things must have gone off air after tom's last email, and one can understand that). But an analysis, or atleast a pointer may be of help to someone (like me) reading this list.

Thanks
Robins


---------- Forwarded message ----------
From: Tom Lane < tgl@sss.pgh.pa.us>
Date: Apr 13, 2007 10:08 AM
Subject: Re: [PERFORM] Strangely Variable Query Performance
To: Steve <cheetah@tanabi.org>
Cc: Scott Marlowe < smarlowe@g2switchworks.com >, PostgreSQL Performance <pgsql-performance@postgresql.org>

Steve < cheetah@tanabi.org> writes:
> On Thu, 12 Apr 2007, Tom Lane wrote:
>> I'm still not having any luck reproducing the failure here.  Grasping at
>> straws again, I wonder if it's got something to do with the order in
>> which the planner examines the indexes --- which is OID order.  Could
>> you send me the results of

> Here you go:

Nope, still doesn't fail for me.  [ baffled and annoyed... ]  There must
be something about your situation that's relevant but we aren't
recognizing it.  Are you in a position to let me ssh into your machine
and try to debug it?  Or other options like sending me a dump of your
database?   I'm about out of steam for tonight, but let's talk about it
off-list tomorrow.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match


------=_Part_57014_5493085.1176781410069--