Hi,
On June 24, 2019 8:19:13 AM PDT, Robert Haas <robertmhaas@gmail.com> wrote:
>On Fri, Jun 21, 2019 at 7:01 PM Alexander Korotkov
><a.korotkov@postgrespro.ru> wrote:
>> On Thu, Mar 28, 2019 at 8:30 AM Thomas Munro <thomas.munro@gmail.com>
>wrote:
>> > Thanks for the reviews! Pushed.
>>
>> Any ideas we should move towards 64-bit xids in more places? That
>has
>> been discussed several times already. I think last time it was
>> discussed in person during FOSDEM PGDay 2018 Developer Meeting [1].
>> There we've discussed that it probably doesn't worth it to change
>> 32-bit on-disk xids in heap. It's better to leave existing heap "as
>> is", but allow other pluggable table access methods to support 64-bit
>> xids. Given now we have pluggable table access methods, we may build
>> a plan on full support of 64-bit xids in core.
>>
>> In my vision sketchy plan may look like this.
>>
>> 1. Change all non-heap types of xids from TransactionId to
>> FullTransactionId.
>
>I think it's fine to replace TransactionId with FullTransactionId
>without stressing about it too much in code that's not that heavily
>trafficked. However, I'm not sure we can do that across the board. For
>example, converting snapshots to use 64-bit XIDs would mean that in
>the worst case a snapshot will use twice as many cache lines, and that
>might have performance implications on some workloads.
We could probably expand the transaction IDs on access or when computing them for most of these, as usually they'll
largely be about currently running transactions. It e.g. seems sensible to keep the procarray at 32 bit xids, expand
xmin/xmaxto 64 when computing snapshots, and leave the snapshot's transaction ID array at 32xids. That ought to be an
negligibleoverhead.
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
