Re: NULLS LAST performance

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: NULLS LAST performance
Дата
Msg-id AANLkTi=g_Gk=t7R+UoxuU5Gjr8vRVKcMrBOu_iFYELjh@mail.gmail.com
обсуждение исходный текст
Ответ на Re: NULLS LAST performance  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: NULLS LAST performance  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-performance
On Thu, Mar 10, 2011 at 9:55 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Mar 9, 2011 at 6:01 PM, Jim Nasby <jim@nasby.net> wrote:
>> Unfortunately, I don't think the planner actually has that level of knowledge.
>
> Actually, I don't think it would be that hard to teach the planner
> about that special case...
>
>> A more reasonable fix might be to teach the executor that it can do 2 scans of the index: one to get non-null data
anda second to get null data. I don't know if the use case is prevalent enough to warrant the extra code though. 
>
> That would probably be harder, but useful.  I thought about working on
> it before but got sidetracked onto other things.

ISTM this isn't all that different from the case of composite indexes
where you are missing the left most term, or you have an index on
a,b,c (which the server already handles) but user asks for a,b desc,
c. If cardinality on b is low it might pay to loop and break up the
scan.

merlin

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

Предыдущее
От: fork
Дата:
Сообщение: Tuning massive UPDATES and GROUP BY's?
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: Tuning massive UPDATES and GROUP BY's?