Re: [HACKERS] indexes and floats - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] indexes and floats
Date
Msg-id 2768.902328759@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] indexes and floats  ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>)
List pgsql-hackers
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
> No, that isn't what it would do. The parser does know about a heirarchy
> of built-in data types, and would not downgrade a float8 to an int4.

OK, that's good.  But if it knows that much, I'd expect it to be able
to *upgrade* an int4 to a float8 where appropriate.  That's not
happening, as in my prior example:

>> play=> explain select x from f8 where x = 500.0;
>> NOTICE:  QUERY PLAN:
>> Index Scan using f8_i on f8  (cost=2.05 size=1 width=8)
>>
>> play=> explain select x from f8 where x = 500;
>> NOTICE:  QUERY PLAN:
>> Seq Scan on f8  (cost=40.00 size=100 width=8)

The thing that I find peculiar about all this is that the system doesn't
reject the query completely, as you'd expect it to if there were really
a type mismatch problem.  It takes it and just does it a lot slower than
it should.  It seems the type coercion will happen, but too late for the
optimizer to notice.

            regards, tom lane

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] OR clause status
Next
From: "Thomas G. Lockhart"
Date:
Subject: Broken source tree