Re: NULLS LAST performance

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jim Nasby <jim(at)nasby(dot)net>, Mathieu De Zutter <mathieu(at)dezutter(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: NULLS LAST performance
Date: 2011-03-10 16:32:56
Message-ID: AANLkTi=g_Gk=t7R+UoxuU5Gjr8vRVKcMrBOu_iFYELjh@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Thu, Mar 10, 2011 at 9:55 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Mar 9, 2011 at 6:01 PM, Jim Nasby <jim(at)nasby(dot)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 and a 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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Merlin Moncure 2011-03-10 16:45:08 Re: Tuning massive UPDATES and GROUP BY's?
Previous Message Julius Tuskenis 2011-03-10 16:26:00 unexpected stable function behavior