Re: tracking commit timestamps
От | Andres Freund |
---|---|
Тема | Re: tracking commit timestamps |
Дата | |
Msg-id | 20141031064146.GD13584@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: tracking commit timestamps (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-hackers |
On 2014-10-31 14:55:11 +0900, Michael Paquier wrote: > 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 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
В списке pgsql-hackers по дате отправления: