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 по дате отправления: