Re: [PERFORM] rapid degradation after postmaster restart

2004-03-13 Thread Tom Lane
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

Re: [PERFORM] rapid degradation after postmaster restart

2004-03-13 Thread Joe Conway
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.

Re: [PERFORM] rapid degradation after postmaster restart

2004-03-13 Thread Josh Berkus
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

Re: [PERFORM] rapid degradation after postmaster restart

2004-03-13 Thread Matthew T. O'Connor
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

Re: [PERFORM] Postgresql on SAN

2004-03-13 Thread Joseph Shraibman
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

Re: [PERFORM] Scaling further up

2004-03-13 Thread Marty Scholes
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

[PERFORM] Drop Tables Very Slow in Postgresql 7.2.1

2004-03-13 Thread Maneesha Nunes
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

Re: [PERFORM] High CPU with 7.4.1 after running for about 2 weeks

2004-03-13 Thread Tom Lane
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

Re: [PERFORM] [ADMIN] syslog slowing the database?

2004-03-13 Thread Magnus Naeslund(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