Josh Berkus wrote: > Particularly, the difficulty is that this application gets many small > requests during the day (100 simultaneous uses) and shares a server > with Apache. So I have to be concerned about how much memory each > connection soaks up, during the day. At night, the maintainence tasks > run a few, really massive procedures. > > So I should probably restart Postgres with different settings at night, > hey?
Actually, if you can afford the twice daily changes, it sounds like a great idea. I think you can get new conf settings to take by sending a SIGHUP to the postmaster, so you don't even really need any downtime to do it. Yup, here it is: http://www.postgresql.org/idocs/index.php?runtime-config.html >>I do think you probably could increase Shared Buffers, as 256 is >>pretty small. There's been a lot of debate over the best setting. The >>usual guidance is start at 25% of physical RAM (16384 == 128MB if you >>have 512MB RAM), then tweak to optimize performance for your >>application and hardware. > > > Hmmm... how big is a shared buffer, anyway? I'm having trouble > finding actual numbers in the docs. By default it is 8K. It's mentioned here: http://www.postgresql.org/idocs/index.php?kernel-resources.html So, as I mentioned above, Shared Buffers of 16384 == 128MB if you have a default 8K block size. >>Are you on a Linux server -- if so I found that >>fdatasync works better than (the default) fsync for wal_sync_method. > > Yes, I am. Any particular reason why fdatasync works better? I can't remember the technical reason (although I've seen one on the list before), but I have determined it empirically true, at least for my setup. Ahh, here we go: http://archives.postgresql.org/pgsql-hackers/1998-04/msg00326.php Joe ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
