Re: Paged Query - Mailing list pgsql-performance

From Shaun Thomas
Subject Re: Paged Query
Date
Msg-id 4FFADB02.7010300@optionshouse.com
Whole thread Raw
In response to Re: Paged Query  (Craig Ringer <ringerc@ringerc.id.au>)
Responses Re: Paged Query  (Craig James <cjames@emolecules.com>)
Re: Paged Query  (Craig Ringer <ringerc@ringerc.id.au>)
List pgsql-performance
On 07/09/2012 07:02 AM, Craig Ringer wrote:

> Do do cursors.

Did you mean "Do not use cursors" here?

> Then the user goes away on a week's holiday and leaves their PC at
> your "next" button.

This exactly. Cursors have limited functionality that isn't directly
disruptive to the database in general. At the very least, the
transaction ID reservation necessary to preserve a cursor long-term can
wreak havoc on your transaction ID wraparound if you have a fairly busy
database. I can't think of a single situation where either client
caching or LIMIT/OFFSET can't supplant it with better risk levels and costs.

--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-444-8534
sthomas@optionshouse.com



______________________________________________

See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email

pgsql-performance by date:

Previous
From: Stanislaw Pankevich
Date:
Subject: Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
Next
From: Craig James
Date:
Subject: Re: Paged Query