"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
Hi,
David Shadovitz wrote, On 1/11/2004 7:10 PM:
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 quer
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.
> >>>
>
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 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 d
> 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 whet
> 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:
>
> SE
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 "
> 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
" clause, so $pg_numrows is m.
And retrieving all results
On Sunday 11 January 2004 18:10, David Shadovitz wrote:
> 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 b
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 FROM WHERE L
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 FROM WHERE LIMIT m
OFFSET n
The other is identical except that I replace the select list with
COUNT(*)
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 FROM WHERE
13 matches
Mail list logo
