Re: sequential scan on select distinct

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: sequential scan on select distinct
Дата
Msg-id 29712.1097094003@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: sequential scan on select distinct  (Greg Stark <gsstark@mit.edu>)
Список pgsql-performance
Greg Stark <gsstark@mit.edu> writes:
> But regardless of how uncommon it is, it could be considered important in
> another sense: when you need it there really isn't any alternative. It's an
> algorithmic improvement with no bound on the performance difference.

[ shrug... ]  There are an infinite number of special cases for which
that claim could be made.  The more we load down the planner with
seldom-useful special cases, the *lower* the overall performance will
be, because we'll waste cycles checking for the special cases in every
case ...

In this particular case, it's not merely a matter of the planner, either.
You'd need some new type of plan node in the executor, so there's a
pretty fair amount of added code bulk that will have to be written and
then maintained.

I'm open to being persuaded that this is worth doing, but the bar is
going to be high; I think there are a lot of other more-profitable ways
to invest our coding effort and planning cycles.

            regards, tom lane

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

Предыдущее
От: Doug Y
Дата:
Сообщение: The never ending quest for clarity on shared_buffers
Следующее
От: Gabriele Bartolini
Дата:
Сообщение: Data warehousing requirements