From: | Morris de Oryx <morrisdeoryx(at)gmail(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Detailed questions about pg_xact_commit_timestamp |
Date: | 2019-07-08 22:22:14 |
Message-ID: | CAKqncchXj_XF7UWm=zmpWp8hzz7hhkPcE_tBa-7fLTRjs2MRaQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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!
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2019-07-08 22:23:13 | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) |
Previous Message | Stephen Frost | 2019-07-08 22:04:46 | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) |