On 9/5/07, Carlo Stonebanks <stonec.register@xxxxxxxxxxxx> wrote: > >> Large shared_buffers and Windows do not mix. Perhaps you should leave > the shmem config low, so that the kernel can cache the file pages. > << > > Is there a problem BESIDES the one that used to cause windows to fail to > allocate memory in blocks larger than 1.5GB? > > The symptom of this problem was that postgresql would just refuse to > restart. Microsoft released a patch for this problem and we can now start > postgresql with larger shared buffers. If this is indeed the problem that > you refer to - and it has indeed been solved by Microsoft - is there a down > side to this? There have been some reports that performance-wise large shared buffer settings don't work as well on windows as they do on linux / unix. Don't know myself. Just what I've read. > >> It sounds like you will need a huge lot of vacuuming effort to keep up. > Maybe you should lower autovac scale factors so that your tables are > visited more frequently. A vacuum_delay of 40 sounds like too much > though. > << > > Does autovacuum not impede performance while it is vacuuming a table? Of course vacuum impedes performance. Depends on your I/O subsystem. By adjusting your vacuum parameters in postgresql.conf, the impact can be made pretty small. But not vacuuming has a slow but sure deteriorating effect over time. So, it's generally better to let autovacuum take care of things and run vacuum with a reasonable set of parameters so it doesn't eat all your I/O bandwidth. ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
