On Mon, Jul 9, 2012 at 6:22 AM, Shaun Thomas <sthomas@xxxxxxxxxxxxxxxx> wrote:
A good solution to this general problem is "hitlists." I wrote about this concept before:
http://archives.postgresql.org/pgsql-performance/2010-05/msg00058.php
Craig James (the other Craig)
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.
A good solution to this general problem is "hitlists." I wrote about this concept before:
http://archives.postgresql.org/pgsql-performance/2010-05/msg00058.php
Craig James (the other Craig)
--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-444-8534
sthomas@xxxxxxxxxxxxxxxx
______________________________________________
See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
