Re: [HACKERS] indexes and floats

> 1. select ... where x = constant; is optimized to an index scan
> only if the constant is of the exact type of the field x.
> Apparently, the coercion of the constant to match the type of x
> happens only after the optimizer decides it doesn't know what to do.
> The coercion ought to happen *before* the optimizer runs.
> (I have no idea whether this is a new bug caused by the recent
> type-system changes, or whether it existed in 6.3.2 and earlier.)

I think the current sources Thomas has modified work better, perhaps?

>
> 2. Type coercion fails for "500.0 :: float4" (ditto for "500.0 :: float8"
> btw). Presumably this is a simple localized bug in the parser or the type
> coercion logic for floats.
>
> I had previously complained of bug #1 in connection with OIDs;
> with the present sources, "where oid = 123456" will not use
> an index on OID, while "where oid = 123456::oid" will.
>
> I will bet lunch (at the nearest McD's, I'm not rich ;-)) that
> Vince Vielhaber's recent gripe about
> select city from locations where lower(city) = lower('st. ignace');
> failing to use an index
> create index locations_city on locations(lower(city) text_ops);
> is an artifact of the same sort of type-mismatch problem.
>
> regards, tom lane
>
>

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)