Re: Need advice to avoid ORDER BY

From: Condor <condor(at)stz-bg(dot)com>
To: <pgsql-general(at)postgresql(dot)org>
Subject: Re: Need advice to avoid ORDER BY
Date: 2013-04-05 09:54:14
Message-ID: e7e1bdf22db01c46f82b266e833cc14a@stz-bg.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 2013-04-05 01:54, Merlin Moncure wrote:
> On Thu, Apr 4, 2013 at 5:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
>>> problem is that you are looking for needles (valids = 0) in the
>>> haystack. the problem wasn't really the order, but the fact that
>>> you
>>> had to scan an arbitrary amount of rows before finding a candidate
>>> record. so the partial index manages this problem by creating index
>>> entries *only for records that match a criteria*, and the planner
>>> recognizes this and prefers that index when the criteria is also
>>> present in the query. In other words, index only the needles.
>>
>> The other way to fix it is a two-column index on (valids, id), which
>> will be more useful if sometimes you need the minimum/maximum id
>> for some nonzero value of valids.
>
> right -- that's a more general solution -- here we are exploiting that
> A: the OP only needs access to "=0" rows and especially B: "=0" rows
> are a tiny fraction of the overall set (we know this because otherwise
> the query would have returned quickly anyways). So we get to squeak
> out with a tiny index pointing to only the candidate rows.
>
> Partial indexes are an underutilized trick -- the efficiency savings
> can be enormous. They are often useful when coding ad hoc queue
> operations in the database where the queued items are intermixed with
> items that have been resolved.
>
> merlin

Thank you for every one for suggestions. I'll try to make
changes tomorrow night to see what will be happened.

Cheers,
Condor

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Magnus Hagander 2013-04-05 10:44:55 Re: High CPU usage of stats collector
Previous Message Dmitriy Igrishin 2013-04-05 08:45:10 Re: OID of type by name.