Re: 8.4 open item: copy performance regression?
От | Kevin Grittner |
---|---|
Тема | Re: 8.4 open item: copy performance regression? |
Дата | |
Msg-id | 4A3FA0CB0200002500027E52@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: 8.4 open item: copy performance regression? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: 8.4 open item: copy performance regression?
Re: 8.4 open item: copy performance regression? Re: 8.4 open item: copy performance regression? |
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: