Re: tracking commit timestamps

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: tracking commit timestamps
Дата
Msg-id CAB7nPqQPrzgv80Tqz-QVXnOazrjgesNX06ug+wLdyG3hoTP-pg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: tracking commit timestamps  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: tracking commit timestamps
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: WAL format and API changes (9.5)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: TAP test breakage on MacOS X