Re: NULLS LAST performance - Mailing list pgsql-performance

From Merlin Moncure
Subject Re: NULLS LAST performance
Date
Msg-id AANLkTi=g_Gk=t7R+UoxuU5Gjr8vRVKcMrBOu_iFYELjh@mail.gmail.com
Whole thread Raw
In response to Re: NULLS LAST performance  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: NULLS LAST performance  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: fork
Date:
Subject: Tuning massive UPDATES and GROUP BY's?
Next
From: Merlin Moncure
Date:
Subject: Re: Tuning massive UPDATES and GROUP BY's?