Message-ID: <4FFADB02.7010300@optionshouse.com>
Date: Mon, 9 Jul 2012 08:22:10 -0500
From: Shaun Thomas <sthomas@optionshouse.com>
Reply-To: <sthomas@optionshouse.com>
Organization: Peak6
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: Craig Ringer <ringerc@ringerc.id.au>
CC: Gregg Jaskiewicz <gryzman@gmail.com>, Misa Simic <misa.simic@gmail.com>,
	Hermann Matthes <hermann.matthes@web.de>,
	<pgsql-performance@postgresql.org>
Subject: Re: Paged Query
References: <4FF43638.5080301@web.de>
	<CAH3i69=B7VPj0rkbuxv9TLEF6V0DjB2xzcEUkf8U7BYULCOBug@mail.gmail.com>
	<CAJY59_icde+87mo65fJT8v9GdOTFemQFMNg5mxy52GCgjVe85w@mail.gmail.com>
	<4FFAC85E.4010607@ringerc.id.au>
In-Reply-To: <4FFAC85E.4010607@ringerc.id.au>
Content-Type: text/plain; charset="UTF-8"; format=flowed
content-transfer-encoding: 7bit

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