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
Probably my best solution is to find a better way to produce the
information, or cache it on the
application side, as it doesn't actually change that much across client
sessions.
Clustering it occurred to me - it would have to be done on a frequent
basis, as the contents
of the table change con
> 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
Spiegelberg, Greg kirjutas P, 11.01.2004 kell 18:21:
> It would seem we're experiencing somthing similiar with our scratch
> volume (JFS mounted with noatime).
Which files/directories do you keep on "scratch" volume ?
All postgres files or just some (WAL, tmp) ?
-
Hannu
---
Hannu Krosing wrote:
Spiegelberg, Greg kirjutas P, 11.01.2004 kell 18:21:
It would seem we're experiencing somthing similiar with our scratch
volume (JFS mounted with noatime).
Which files/directories do you keep on "scratch" volume ?
All postgres files or just some (WAL, tmp) ?
No Postgres fil
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 "
Dear developers,
I wonder it happens to systems where inefficient update
SQL's are used like this:
UPDATE MyTable SET MyColumn=1234
Question arises when the value of MyColumn is already 1234
before the update.
If I am right, even when the to-be-updated column values
equal to the new values,
"cnliou" <[EMAIL PROTECTED]> writes:
> I wonder it happens to systems where inefficient update
> SQL's are used like this:
> UPDATE MyTable SET MyColumn=1234
> Question arises when the value of MyColumn is already 1234
> before the update.
We have to fire UPDATE triggers in any case.
> If I am
