Re: max_wal_senders must die

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: max_wal_senders must die
Date: 2010-10-21 01:54:19
Message-ID: AANLkTimcaOSMCRjQpctatoqzVQospi=vhDjV_FfLNBsy@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 20, 2010 at 6:17 PM, Josh Berkus <josh(at)agliodbs(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Itagaki Takahiro 2010-10-21 01:57:15 Re: Extensions, this time with a patch
Previous Message Nathan Boley 2010-10-21 01:53:13 Re: default_statistics_target WAS: max_wal_senders must die