Re: AW: AW: More Performance

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: AW: AW: More Performance
Дата
Msg-id 22624.959266255@sss.pgh.pa.us
обсуждение исходный текст
Ответ на AW: AW: More Performance  (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>)
Список pgsql-hackers
Zeugswetter Andreas SB <ZeugswetterA@Wien.Spardat.at> writes:
> But, it probably shows a problem with the chosen metric for
> selectivity itself.  Imho the chances are better, that an =
> restriction will return an equal amount of rows while the table grows
> than that it will return a percentage of total table size.

Unfortunately you are allowing your thinking to be driven by a single
example.  Consider queries likeselect * from employees where dept = 'accounting';
It's perfectly possible that the column being tested with '=' has only
a small number of distinct values, in which case the number of retrieved
rows probably *is* proportional to the table size.

I am not willing to change the planner so that it "guarantees" to choose
an indexscan no matter what, because then it would be broken for cases
like this.  We have to look at the statistics we have, inadequate though
they are.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Michael A. Olson"
Дата:
Сообщение: Re: AW: Berkeley DB...
Следующее
От: Tom Lane
Дата:
Сообщение: Re: understanding Datum -> char * -> Datum conversions