Re: Master-slave visibility order

On 2013-08-30 00:22:49 +0300, Ants Aasma wrote:
> Hi, thanks for your reply.
> 
> On Thu, Aug 29, 2013 at 6:40 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> > I think approach #2 is dead on arrival, at least as a default policy.
> > It essentially amounts to requiring two commit records per transaction
> > rather than one, and I think that has no chance of being acceptable.
> > It's not just or even primarily the *volume* of WAL that I'm concerned
> > about so much as the feeling that hitting WAL twice rather than once
> > at the end of a transaction that may have only written one or two WAL
> > records to begin with is going to slow things down pretty
> > substantially, especially in high-concurrency scenarios.
> 
> Heikki's excellent work on WAL insert scaling improves this so the hit
> might not be all that big, considering that the visibility record only
> needs to be inserted - relatively cheap compared to a WAL sync. But
> it's still not likely to be free. I guess the only way to know for
> sure would be to build it and bench it.

FWIW, WAL is still the major bottleneck for INSERT heavy workloads. The
per CPU overhead actually minimally increased (at least in my tests), it
just scales noticeably better than before.

But I think that actually coordinating a consistent visibility order
between commit, wal insertion and the procarray would have bigger
scalability impact than the second record. I might be missing some
clever tricks here though.

> > If you did choose to implement #2 as an option at some point, it would
> > probably be worth optimizing for the case where commit ordering and
> > visibility ordering match, and try to find a design where you only
> > need the extra WAL record when the orderings don't match.  I'm not
> > sure exactly how to do that, but it might be worth investigating.  I
> > don't think that's enough to save #2 as a default behavior, but it
> > might make it more palatable as an option.
> 
> Without a side channel the extra WAL record is necessary. Suppose that
> we want to determine the ordering with a single commit record. The
> slave must be able to deduce from the single record if it can make the
> commit immediately visible or should it wait for additional
> information. If it waits for additional information, that may never
> come as the master could have committed and then went idle.

Well, we relatively easily could offload the task of sending such
information to the bgwriter or similar. I don't think that's a
particularly good idea, but it certainly is a possibility.

Andres