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@candle.pha.pa.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)