Re: [PERFORM] COUNT Pagination

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

Re: [PERFORM] COUNT Pagination

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

[PERFORM] COUNT Pagination

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

Re: [PERFORM] Why is restored database faster?

Dennis, Shridhar, and Neil, Thanks for your input. Here are my responses: I ran VACUUM FULL on the table in question. Although that did reduce Pages and UnUsed, the SELECT * query is still much slower on this installation than in the new, restored one. Old server: # VACUUM FULL abc;

[PERFORM] Why is VACUUM ANALYZE table so slow?

I'm running PG 7.2.2 on RH Linux 8.0. I'd like to know why VACUUM ANALYZE table is extemely slow (hours) for certain tables. Here's what the log file shows when I run this command on my employees table, which has just 5 columns and 55 records: VACUUM ANALYZE employees DEBUG: --Relation

Re: [PERFORM] Measuring execution time for sql called from PL/pgSQL

I've tried to measure the duration of sql with printing out localtimestamp but for some reason during the same pg/plsql call it returns the same value: Aram, From http://www.postgresql.org/docs/current/static/functions-datetime.html: There is also the function timeofday(), which for

Re: [PERFORM] Why is VACUUM ANALYZE table so slow?

PostgreSQL. -David On Tuesday, December 16, 2003 2:51 PM, Neil Conway [SMTP:[EMAIL PROTECTED] wrote: David Shadovitz [EMAIL PROTECTED] writes: I'm running PG 7.2.2 on RH Linux 8.0. Note that this version of PostgreSQL is quite old. I'd like to know why VACUUM ANALYZE table is extemely slow (hours

[PERFORM] Why is restored database faster?

I backed up my database using pg_dump, and then restored it onto a different server using psql. I see that the query SELECT COUNT(*) FROM myTable executes immediately on the new server but takes several seconds on the old one. (The servers are identical.) What could account for this

[PERFORM] Query plan - now what?

Well, now that I have the plan for my slow-running query, what do I do? Where should I focus my attention? Thanks. -David Hash Join (cost=16620.59..22331.88 rows=40133 width=266) (actual time=118773.28..580889.01 rows=57076 loops=1) - Hash Join (cost=16619.49..21628.48 rows=40133

Re: [PERFORM] Query plan - now what?

This is not very informative when you didn't show us the query nor the table schemas.. BTW, what did you do with this, print and OCR it? Tom, I work in a classified environment, so I had to sanitize the query plan, print it, and OCR it. I spent a lot of time fixing typos, but I guess at