Re: Poor OFFSET performance in PostgreSQL 9.1.6

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: fburgess(at)radiantblue(dot)com
Cc: postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Poor OFFSET performance in PostgreSQL 9.1.6
Date: 2013-08-28 23:10:37
Message-ID: CAHyXU0yUzyX1UF_Ec8LrR_4c_NkhM1k8TPffBaFzrKPq_tgyDg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, Aug 28, 2013 at 3:39 PM, <fburgess(at)radiantblue(dot)com> wrote:
> Can anyone offer suggestions on how I can optimize a query that contains the
> LIMIT OFFSET clause?
>
> The explain plan of the query is included in the notepad attachment.

OFFSET is working as designed (that is, slowly). Managing pagination
with OFFSET is essentially a hack and will not scale to even medium
sized tables. You have some SQL alternatives. One is cursors as
greg mentioned. Another is client side pagination:

Select * from labor_task_report this_
inner join labor_tasks labor1_ on this_.labor_UID=20178
order by
labor1_START_TIME asc,
this_.work_DATE_TIME asc,
this_.work_UID asc,
this_.task_REPORT_UID
limit 10000 offset 940000;

could become

Select * from labor_task_report this_
inner join labor_tasks labor1_ on this_.labor_UID=20178
where (
labor1_START_TIME,
this_.work_DATE_TIME asc,
this_.work_UID asc,
this_.task_REPORT_UID) >
($1, $2, $3, $4)
order by
labor1_START_TIME asc,
this_.work_DATE_TIME asc,
this_.work_UID asc,
this_.task_REPORT_UID
limit 10000;

where $1-$4 are the corresponding fields of the last row you read from
the last fetch.

merlin

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message David Rowley 2013-08-29 04:43:50 Re: Poor OFFSET performance in PostgreSQL 9.1.6
Previous Message fburgess 2013-08-28 22:08:16 Re: Poor OFFSET performance in PostgreSQL 9.1.6