Re: Proposal for CSN based snapshots - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Proposal for CSN based snapshots
Date
Msg-id CA+Tgmob1DmDsvc7iyd0SY5j4SFdesDwoef36bxG1pE_s1JQXOQ@mail.gmail.com
Whole thread Raw
In response to Re: Proposal for CSN based snapshots  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Proposal for CSN based snapshots  (Andres Freund <andres@anarazel.de>)
Re: Proposal for CSN based snapshots  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Fri, Jul 24, 2015 at 1:00 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> It depends on the exact design we use to get that. Certainly we do not want
> them if they cause a significant performance regression.

Yeah.  I think the performance worries expressed so far are:

- Currently, if you see an XID that is between the XMIN and XMAX of
the snapshot, you hit CLOG only on first access.  After that, the
tuple is hinted.  With this approach, the hint bit doesn't avoid
needing to hit CLOG anymore, because it's not enough to know whether
or not the tuple committed; you have to know the CSN at which it
committed, which means you have to look that up in CLOG (or whatever
SLRU stores this data).  Heikki mentioned adding some caching to
ameliorate this problem, but it sounds like he was worried that the
impact might still be significant.

- Mixing synchronous_commit=on and synchronous_commit=off won't work
as well, because if the LSN ordering of commit records matches the
order in which transactions become visible, then an async-commit
transaction can't become visible before a later sync-commit
transaction.  I expect we might just decide we can live with this, but
it's worth discussing in case people feel otherwise.

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



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: optimizing vacuum truncation scans
Next
From: Andrew Dunstan
Date:
Subject: Re: "make check" changes have caused buildfarm deterioration.