| 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: | Whole Thread | Raw Message | 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
| 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 |