Re: Query Plan far worse in 7.3.2 than 7.2.1

Tom,
    You hit the nail on the head, foreign_key is a varchar(250).  I'll re-write
the queries with explicit casts.
    I'm hesitant to say anything, because I'm really not in a position to
contribute, but... It seems like there are getting to be lots of typing
issues (this one, 2 isn't an int8, etc.)  I think that people have said that
things are like this to support user defined data types.  I would happily
get rid of user defined data types if it would help with the type conversion
issues.  Just my 2c, for what it's worth.
Thanks,
Peter Darley

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Wednesday, April 30, 2003 7:54 AM
To: Peter Darley
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Query Plan far worse in 7.3.2 than 7.2.1


"Peter Darley" <pdarley@kinesis-cem.com> writes:
> SELECT COUNT(*) FROM Border_Shop_List  WHERE NOT EXISTS (SELECT
Foreign_Key=
>  FROM Sample WHERE Foreign_Key=3D'Quantum_' ||
Border_Shop_List.Assignment_=
> ID || '_' || Assignment_Year || '_' || Evaluation_ID)

What's the datatype of Foreign_Key?

I'm betting that it's varchar(n) or char(n).  The result of the ||
expression is text, and so the comparison can't use a varchar index
unless you explicitly cast it to varchar:
    WHERE Foreign_Key = ('Quantum_' || ... || Evaluation_ID)::varchar

I think 7.2 had some kluge in it that would allow a varchar index to be
used anyway, but we took out the kluge because it was semantically wrong
(it would also allow use of a char(n) index in place of a text
comparison, which alters the semantics...)

            regards, tom lane