Envelope-to: pgsql-sql@postgresql.org
Message-ID: <4BEBAC15.4030105@bankir.ru>
Date: Thu, 13 May 2010 11:36:53 +0400
From: silly sad <sad@bankir.ru>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5)
	Gecko/20100111 Thunderbird/3.0
MIME-Version: 1.0
To: pgsql-sql@postgresql.org
Subject: Re: best paging strategies for large datasets?
References: <20100512054144.GA8762@apartia.fr>
In-Reply-To: <20100512054144.GA8762@apartia.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 05/12/10 09:41, Louis-David Mitterrand wrote:
> Hi,
>
> I have a large dataset (page 1 at http://www.cruisefish.net/stat.md) and
> am in the process of developping a pager to let users leaf through it
> (30K rows).
>
> Ideally I'd like to know when requesting any 'page' of data where I am
> within the dataset: how many pages are available each way, etc.
>
> Of course that can be done by doing a count(*) query before requesting a
> limit/offset subset. But the main query is already quite slow, so I'd
> like to minimize them.

nowadays i tend to bet on AJAX.
in other words i propose to move some calculations to a client side at all.

and this particular situation might looks similar to the following:

First u count(*) the rows and select a requested page
returning to a client the count result bundled "with a page of rows"

(1) client renders the acquired rows
(2)__memorize__ what part of the data he just got
(3) and stores the count result to calculate "the pager div"

all the subsequent clicks on "the pager div" should not immediately 
generate requests and decides if the request is needed.