On 08/10/2016 08:28 AM, Robert Haas wrote:
> On Wed, Aug 10, 2016 at 11:09 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>>> Still, having to invent CSNs seems like a huge loss for this design.
>>> Personally I'd give up async commit first. If we had only sync commit,
>>> the rule could be "xact LSN less than snapshot threshold and less than
>>> WAL flush position", and we'd not need CSNs. I know some people like
>>> async commit, but it's there because it was easy and cheap in our old
>>> design, not because it's the world's greatest feature and worth giving
>>> up performance for.
>>
>> I don't think that's a very popular opinion (I disagree, for one).
>> Asynchronous commits are a huge performance boost for some applications. The
>> alternative is fsync=off, and I don't want to see more people doing that.
>> SSDs have made the penalty of an fsync much smaller, but it's still there.
>
> Uh, yeah. Asynchronous commit can be 100 times faster on some
> realistic workloads. If we remove it, many people will have to decide
> between running with fsync=off and abandoning PostgreSQL altogether.
> That doesn't strike me as a remotely possible line of attack.
+1 for Robert here, removing async commit is a non-starter. It is
PostgreSQL performance 101 that you disable synchronous commit unless
you have a specific data/business requirement that needs it.
Specifically because of how much faster Pg is with async commit.
Sincerely,
jD
>
--
Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
Unless otherwise stated, opinions are my own.
