On 9/5/07, Carlo Stonebanks <stonec.register@sympatico.ca> 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.
