Joe Conway [EMAIL PROTECTED] writes:
... Immediately
after a postmaster restart, the first insert or two take about 1.5
minutes (undoubtedly this could be improved, but it isn't the main
issue). However by the second or third insert, the time increases to 7 -
9 minutes. Restarting the
Marty Scholes wrote:
I have seen similar results to what you are describing.
I found that running a full vacuum:
vacuumdb -fza
followed by a checkpoint makes it run fast again.
Try timing the update with and without a full vacuum.
Will do. I'll let you know how it goes.
Thanks for the reply.
Joe,
IIRC, shared buffers was reasonable, maybe 128MB. One thing that is
worthy of note is that they are using pg_autovacuum and a very low
vacuum_mem setting (1024). But I also believe that max_fsm_relations and
max_fsm_pages have been bumped up from default (something like 1
Joe Conway wrote:
Tom Lane wrote:
Just to be clear on this: you have to restart the postmaster to bring
the time back down? Simply starting a fresh backend session doesn't do
it?
IIRC, shared buffers was reasonable, maybe 128MB. One thing that is
worthy of note is that they are using
Josh Berkus wrote:
See above. Also keep in mind that PostgreSQL's use of I/O should improve
100% in version 7.5.
Really? What happened?
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send
I have some suggestions based on my anecdotal experience.
1. This is a relatively small DB -- the working set will likely be in
RAM at any moment in time, making read I/O time mostly irrelevant.
2. The killer will be write times -- specifically log writes. Small and
heavily synchronized
Hello there !!!
I am using postgresql7.2.1 as the backend for an E.R.P system running
on Linux Redhat 7.2(Enigma)
The database size is around 20-25GB
Dropping of an individual table whose size is around 200Mb takes more
than 7 mins, and also increases the load on our System
The database is
Mike Bridge [EMAIL PROTECTED] writes:
I've been running Postgresql 7.4.1 for a couple weeks after upgrading
from 7.2. I noticed today that the postmaster had been using 99% of
the dual CPUs (on a PowerEdge 2650) non-stop for the last couple days.
I stopped all the clients, and it didn't
Tom Lane wrote:
Greg Spiegelberg [EMAIL PROTECTED] writes:
I turned syslog back on and the restore slowed down again. Turned
it off and it sped right back up.
We have heard reports before of syslog being quite slow. What platform
are you on exactly? Does Richard's suggestion of turning off