On Thu, 18 Dec 2003, Shridhar Daithankar wrote:
> Well, then the only issue left is file sytem defragmentation.
And the internal fragmentation that can be "fixed" with the CLUSTER
command.
--
/Dennis
---(end of broadcast)---
TIP 7: don't forget
On Thursday 18 December 2003 09:24, David Shadovitz wrote:
> Old server:
> # VACUUM FULL abc;
> VACUUM
> # VACUUM VERBOSE abc;
> NOTICE: --Relation abc--
> NOTICE: Pages 1526: Changed 0, Empty 0; Tup 91528; Vac 0, Keep 0, UnUsed
> 32. Total CPU 0.07s/0.52u sec elapsed 0.60 sec.
> VACUUM
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;
On Tue, 16 Dec 2003, David Shadovitz wrote:
> 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
Neil Conway wrote:
How can I get the original server to perform as well as the new one?
Well, you have the answer. Dump the database, stop postmaster and restore it.
That should be faster than original one.
(BTW, "SELECT count(*) FROM table" isn't a particularly good DBMS
performance indication.
David Shadovitz <[EMAIL PROTECTED]> writes:
> What could account for this difference?
Lots of things -- disk fragmentation, expired tuples that aren't being
cleaned up by VACUUM due to a long-lived transaction, the state of the
kernel buffer cache, the configuration of the kernel, etc.
> How can
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 differe
