scott.marlowe [EMAIL PROTECTED] writes:
Yes, previously run query should be faster, if it fits in kernel
cache.
Or the PostgreSQL buffer cache.
Plus, the design of Postgresql is such that it would have to do a
LOT of cache checking to see if there were any updates to the
underlying data
scott.marlowe wrote:
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:
On Wed, 14 Jan 2004, Rajesh Kumar Mallah wrote:
scott.marlowe wrote:
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
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
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
If you only need the count when you've got the results, most PG client
interfaces will tell you how many rows you've got. What language is your app
in?
PHP.
But I have only a subset of the results, retrieved via a query with a LIMIT
m clause, so $pg_numrows is m.
And retrieving all results
On Mon, 2004-01-12 at 10:37, David Shadovitz wrote:
If you only need the count when you've got the results, most PG client
interfaces will tell you how many rows you've got. What language is your app
in?
PHP.
But I have only a subset of the results, retrieved via a query with a LIMIT
m
So I'm looking for advice on displaying paginated query results.
Displaying 1 to 50 of 2905.
1-50 | 51-100 | 101-150 | etc.
I do this by executing two queries. One is of the form:
SELECT select list FROM view/table list WHERE filter LIMIT m
OFFSET n
The other is identical except that I
I understand that COUNT queries are expensive. So I'm looking for advice on
displaying paginated query results.
I display my query results like this:
Displaying 1 to 50 of 2905.
1-50 | 51-100 | 101-150 | etc.
I do this by executing two queries. One is of the form:
SELECT select list
