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(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Wednesday, April 30, 2003 7:54 AM
To: Peter Darley
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] Query Plan far worse in 7.3.2 than 7.2.1

"Peter Darley" <pdarley(at)kinesis-cem(dot)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