Re: COUNT & Pagination

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: David Shadovitz <david(at)www(dot)shadovitz(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, <mallah(at)trade-india(dot)com>
Subject: Re: COUNT & Pagination
Date: 2004-01-13 17:55:59
Message-ID: Pine.LNX.4.33.0401131054200.22609-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, 13 Jan 2004, David Shadovitz wrote:

> > We avert the subsequent execution of count(*) by passing the
> > value of count(*) as a query parameter through the link in page
> > numbers.
>
> Mallah, and others who mentioned caching the record count:
>
> Yes, I will certainly do this. I can detect whether the query's filter has
> been changed, or whether the user is merely paging through the results or
> sorting* the results.
>
> I'd love to completely eliminate the cost of the COUNT(*) query, but I guess
> that I cannot have everything.
>
> * My HTML table column headers are hyperlinks which re-execute the query,
> sorting the results by the selected column. The first click does an ASC
> sort; a second click does a DESC sort.

another useful trick is to have your script save out the count(*) result
in a single row table with a timestamp, and every time you grab if, check
to see if x number of minutes have passed, and if so, update that row with
a count(*). You can even have a cron job do it so your own scripts don't
incur the cost of the count(*) and delay output to the user.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Jón Ragnarsson 2004-01-14 12:42:21 100 simultaneous connections, critical limit?
Previous Message David Shadovitz 2004-01-13 17:45:33 Re: COUNT & Pagination