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
|
| Список | 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 по дате отправления: