Re: why Sequencial Scan when selecting on primary key of table?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rod Taylor <rbt(at)rbt(dot)ca>
Cc: Brian Tarbox <btarbox(at)theworld(dot)com>, Postgresql Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: why Sequencial Scan when selecting on primary key of table?
Date: 2003-05-31 18:12:30
Message-ID: 21406.1054404750@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Rod Taylor <rbt(at)rbt(dot)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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Dave E Martin XXIII 2003-05-31 22:56:56 Re: Index speeds up one row table (why)?
Previous Message Andrew Sullivan 2003-05-31 18:02:35 Re: why Sequencial Scan when selecting on primary key of table?