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@xxxxxxxxxxxxx>
Date: Apr 13, 2007 10:08 AM
Subject: Re: [PERFORM] Strangely Variable Query Performance
To: Steve <cheetah@xxxxxxxxxx>
Cc: Scott Marlowe <smarlowe@xxxxxxxxxxxxxxxxx
>, PostgreSQL Performance <pgsql-performance@xxxxxxxxxxxxxx>
Steve <cheetah@xxxxxxxxxx> 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
--
Robins
