Detailed questions about pg_xact_commit_timestamp - Mailing list pgsql-hackers

From Morris de Oryx
Subject Detailed questions about pg_xact_commit_timestamp
Date
Msg-id CAKqncchXj_XF7UWm=zmpWp8hzz7hhkPcE_tBa-7fLTRjs2MRaQ@mail.gmail.com
Whole thread Raw
Responses Re: Detailed questions about pg_xact_commit_timestamp  (Adrien Nayrat <adrien.nayrat@anayrat.info>)
List pgsql-hackers
I have some specific questions about pg_xact_commit_timestamp, and am hoping that this is the right place to ask. I read a lot of the commentary about the original patch, and the contributors seem to be here. If I'm asking in the wrong place, just let me know.

I'm working on a design for a concurrency-safe incremental aggregate rollup system,and pg_xact_commit_timestamp sounds perfect. But I've found very little commentary on it generally, and couldn't figure out how it works in detail from the source code.

Hopefully, someone knows the answers to a few questions:

* Is it possible for pg_xact_commit_timestamp to produce times out of order? What I'm after is a way to identify records that have been chagned since a specific time so that I can get any later changes for processing. I don't need them in commit order, so overlapping timestamps aren't a problem. 

* How many bytes are added to each row in the final implementation? The discussions I saw seemed to be ranging from 12-24 bytes. There was discussion of adding in extra bytes for "just in case." This is pre 9.5, so a world ago.

* Are the timestamps indexed internally? With a B-tree? I ask for capacity-planning reasons.

* I've seen on StackOverflow and the design discussions that the timestamps are not kept indefinitely, but can't find the details on exactly how long they are stored.

* Any rules of thumb on the performance impact of enabling pg_xact_commit_timestamp? I don't need the data on all tables but, where I do, it sounds like it might work perfectly.

Many thanks for any assistance!

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Next
From: Bruce Momjian
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)