Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wonder though whether the wal_buffers setting interacts with the
> ring size. Has everyone who's tested this used the same 16MB
> wal_buffers setting as in Alan's original scenario?
I had been using his postgresql.conf file, then added autovacuum =
off. When I tried with setting the ring size to 16MB, I accidentally
left off the step to copy the postgresql.conf file, and got better
performance. I alternated between the postgresql.conf file from
earlier tests and the default file left there by the initdb, and got
this:
8.4rc1 with 16MB ring, default postgresql.conf
0m23.223s
0m23.489s
0m23.921s
8.4rc1 with 16MB ring, Alan's postgresql.conf
0m28.678s
0m26.171s
0m27.513s
default postgresql.conf (comments stripped)
max_connections = 100
shared_buffers = 32MB
datestyle = 'iso, mdy'
lc_messages = 'C'
lc_monetary = 'C'
lc_numeric = 'C'
lc_time = 'C'
default_text_search_config = 'pg_catalog.english'
Alan's postgresql.conf (comments stripped)
shared_buffers = 256MB
wal_buffers = 16MB
checkpoint_segments = 100
autovacuum = off
I'm not going to claim I know why, but I thought I should report it.
Oh, and the 8.3.7 numbers and pre-patch numbers were averaging the
same under the day-time load as the replication sync mode. So, with
the ring size at 16MB this load is faster under 8.4 than 8.3.
-Kevin