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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: why Sequencial Scan when selecting on primary key of table?
Дата
Msg-id 21406.1054404750@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: why Sequencial Scan when selecting on primary key of table?  (Rod Taylor <rbt@rbt.ca>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Sullivan
Дата:
Сообщение: Re: why Sequencial Scan when selecting on primary key of table?
Следующее
От: "Brian Tarbox"
Дата:
Сообщение: are views typically any faster/slower than equivilent joins?