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 <[EMAIL PROTECTED]>
Date: Apr 13, 2007 10:08 AM
Subject: Re: [PERFORM] Strangely Variable Query Performance
To: Steve <[EMAIL PROTECTED]>
Cc: Scott Marlowe <[EMAIL PROTECTED]>, PostgreSQL Performance <
pgsql-performance@postgresql.org>
Steve <[EMAIL PROTECTED]> 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
