From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
Cc: | hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] indexes and floats |
Date: | 1998-08-05 14:52:39 |
Message-ID: | 2768.902328759@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Thomas G. Lockhart" <lockhart(at)alumni(dot)caltech(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | fcheese | 1998-08-05 15:01:46 | UNSUBSCRIBE! |
Previous Message | Tom Lane | 1998-08-05 14:45:17 | Re: [HACKERS] OR clause status |