Re: tracking commit timestamps - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: tracking commit timestamps
Date
Msg-id CAB7nPqQPrzgv80Tqz-QVXnOazrjgesNX06ug+wLdyG3hoTP-pg@mail.gmail.com
Whole thread Raw
In response to Re: tracking commit timestamps  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: tracking commit timestamps
List pgsql-hackers


On Tue, Oct 28, 2014 at 9:25 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
On 13 October 2014 10:05, Petr Jelinek <petr@2ndquadrant.com> wrote:

>> I worked bit on this patch to make it closer to committable state.

> Here is updated version that works with current HEAD for the October
> committfest.

I've reviewed this and it looks good to me. Clean, follows existing
code neatly, documented and tested.

Please could you document a few things

* ExtendCommitTS() works only because commit_ts_enabled can only be
set at server start.
We need that documented so somebody doesn't make it more easily
enabled and break something.
(Could we make it enabled at next checkpoint or similar?)

* The SLRU tracks timestamps of both xids and subxids. We need to
document that it does this because Subtrans SLRU is not persistent. If
we made Subtrans persistent we might need to store only the top level
xid's commitTS, but that's very useful for typical use cases and
wouldn't save much time at commit.

Hm. What is the performance impact of this feature using the latest version of this patch? I imagine that the penalty of the additional operations this feature introduces is not zero, particularly for loads with lots of short transactions.
--
Michael

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: WAL format and API changes (9.5)
Next
From: Tom Lane
Date:
Subject: Re: TAP test breakage on MacOS X