Re: max_wal_senders must die

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: max_wal_senders must die
Дата
Msg-id AANLkTimcaOSMCRjQpctatoqzVQospi=vhDjV_FfLNBsy@mail.gmail.com
обсуждение исходный текст
Ответ на Re: max_wal_senders must die  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: max_wal_senders must die  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
On Wed, Oct 20, 2010 at 6:17 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> Quite.  Josh, have you got any evidence showing that the penalty is
>> only 10%?  There are cases, such as COPY and ALTER TABLE, where
>> you'd be looking at 2X or worse penalties, because of the existing
>> optimizations that avoid writing WAL at all for operations where a
>> single final fsync can serve the purpose.  I'm not sure what the
>> penalty for "typical" workloads is, partly because I'm not sure what
>> should be considered a "typical" workload for this purpose.
>
> If we could agree on some workloads, I could run some benchmarks.  I'm
> not sure what those would be though, given that COPY and ALTER TABLE
> aren't generally included in most benchmarks.  I could see how
> everything else is effected, though.

I think this whole thing is a complete non-starter.  Are we seriously
talking about shipping a configuration that will slow down COPY by 2X
or more, just so that someone who wants replication can do it by
changing one fewer parameter?  I find it impossible to believe that's
a good decision, and IMHO we should be focusing on how to make the
parameters PGC_SIGHUP rather than PGC_POSTMASTER, which would give us
most of the same benefits without throwing away hard-won performance.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Nathan Boley
Дата:
Сообщение: Re: default_statistics_target WAS: max_wal_senders must die
Следующее
От: Itagaki Takahiro
Дата:
Сообщение: Re: Extensions, this time with a patch