Re: tracking commit timestamps

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>
Subject: Re: tracking commit timestamps
Date: 2014-10-31 06:41:46
Message-ID: 20141031064146.GD13584@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-www

On 2014-10-31 14:55:11 +0900, Michael Paquier wrote:
> On Tue, Oct 28, 2014 at 9:25 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> > On 13 October 2014 10:05, Petr Jelinek <petr(at)2ndquadrant(dot)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 haven't measured it recently, but it wasn't large, but measureable.

> I imagine that the penalty of the additional operations this
> feature introduces is not zero, particularly for loads with lots of short
> transactions.

Which is why you can disable it...

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message furuyao 2014-10-31 08:46:49 Re: pg_receivexlog --status-interval add fsync feedback
Previous Message Tom Lane 2014-10-31 06:03:09 Re: TAP test breakage on MacOS X

Browse pgsql-www by date

  From Date Subject
Next Message Magnus Hagander 2014-10-31 11:11:04 Re: Deal with <>s in message IDs
Previous Message Michael Paquier 2014-10-31 05:55:11 Re: tracking commit timestamps