Re: Slow query with indexed ORDER BY and LIMIT when using OR'd conditions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: johno <jan(dot)suchal(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Slow query with indexed ORDER BY and LIMIT when using OR'd conditions
Date: 2014-07-22 06:15:29
Message-ID: 11612.1406009729@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

johno <jan(dot)suchal(at)gmail(dot)com> writes:
> On Tue, Jul 22, 2014 at 4:53 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> johno <jan(dot)suchal(at)gmail(dot)com> writes:
>>> The obvious query is
>>> SELECT * FROM register_uz_accounting_entities
>>> WHERE effective_on > '2014-07-11' OR (effective_on = '2014-07-11' AND
>>> id > 1459)
>>> ORDER BY effective_on, id
>>> LIMIT 100

>> A more readily optimizable query is
>> SELECT * FROM register_uz_accounting_entities
>> WHERE (effective_on, id) > ('2014-07-11'::date, 1459)
>> ORDER BY effective_on, id
>> LIMIT 100

> Yes, but that query has completely different semantics - I can't change
> that.

No, it doesn't. Read it again ... or read up on row comparisons,
if you're unfamiliar with that notation. The above queries are
exactly equivalent per spec.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Евгений Селявка 2014-07-22 07:38:18 estimate btree index size without creating
Previous Message johno 2014-07-22 05:57:08 Re: Slow query with indexed ORDER BY and LIMIT when using OR'd conditions