Re: COUNT & Pagination

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:
>>
>>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(*).
>

Greetings!

The count(*) can get evaluated with any arbitrary combination
in whre clause how do you plan to store that information ?

In a typical application pagination could be required in n number
of contexts . I would be interested to know more about this trick
and its applicability in such situations.

Offtopic:

Does PostgreSQL optimise repeated execution of similar queries ie
queries on same table or set of tables (in a join) with same where clause
and only differing in LIMIT and OFFSET.

I dont know much about MySQL, Is their "Query Cache" achieving
better results in such cases? and do we have anything similar in
PostgreSQL ? I think the most recently accessed tables anyways
get loaded in shared buffers in PostgreSQL so that its not accessed
from the disk. But is the "Query Cache" really different from this.
Can anyone knowing a little better about the working of MySQLs'
query cache throw some light?

Regds
Mallah.

> 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.
>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>
>
>