Re: why Sequencial Scan when selecting on primary key of table? - Mailing list pgsql-performance

From Tom Lane
Subject Re: why Sequencial Scan when selecting on primary key of table?
Date
Msg-id 21406.1054404750@sss.pgh.pa.us
Whole thread Raw
In response to Re: why Sequencial Scan when selecting on primary key of table?  (Rod Taylor <rbt@rbt.ca>)
List pgsql-performance
Rod Taylor <rbt@rbt.ca> writes:
> Out of curiosity, why don't we confirm the unquoted value is an integer,
> numeric, etc, then change it into type 'unknown'?

UNKNOWNNUMERIC is one of the ideas that's been proposed, but it's not
clear to me that it is better than other alternatives.  In particular,
I don't like losing knowledge of the form and size of the constant.
Something like "WHERE int4col = 4.8" should yield FALSE, not "ERROR:
pg_atoi: unable to parse '4.8'" which is what you're likely to get with
a naive "unknown numeric type" approach.  A perhaps-more-realistic
objection is that it only solves the problem for trivial "var = const"
cases.  As soon as you look at even slightly more complicated
expressions, it stops doing much good.

I'm still of the opinion that the best solution in the long run is to
get rid of most of the cross-datatype numeric operators, but there are
pitfalls there too.  See last thread on the issue:
http://archives.postgresql.org/pgsql-hackers/2002-11/msg00468.php

            regards, tom lane

pgsql-performance by date:

Previous
From: Andrew Sullivan
Date:
Subject: Re: why Sequencial Scan when selecting on primary key of table?
Next
From: "Brian Tarbox"
Date:
Subject: are views typically any faster/slower than equivilent joins?