<div> </div><div>The proposed option does not need to change the length of either the page header or tuple header. Therefore, you will not need to physically change the data.</div><div> </div><div><span style="background:#ffffff;color:#000000;float:none;font:400 15px 'arial' , sans-serif;text-decoration-style:initial;text-indent:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px">regards</span></div><div><br /></div><div><br /></div><div>01.11.2019, 20:10, "Tomas Vondra" <tomas(dot)vondra(at)2ndquadrant(dot)com>:</div><blockquote><p>On Fri, Nov 01, 2019 at 10:25:17AM +0100, Pavel Stehule wrote:<br /></p><blockquote class="b4fd5cf2ec92bc68cb898700bb81355fwmi-quote">Hi<br /><br />pá 1. 11. 2019 v 10:11 odesílatel Павел Ерёмин <<a href="mailto:shnoor111gmail(at)yandex(dot)ru">shnoor111gmail(at)yandex(dot)ru</a>><br />napsal:<br /><br /><blockquote class="b4fd5cf2ec92bc68cb898700bb81355fwmi-quote"> Hi.<br /> sorry for my English.<br /> I want to once again open the topic of 64 bit transaction id. I did not<br /> manage to find in the archive of the option that I want to discuss, so I<br /> write. If I searched poorly, then please forgive me.<br /> The idea is not very original and probably has already been considered,<br /> again I repeat - I did not find it. Therefore, please do not scold me<br /> severely.<br /> In discussions of 64-bit transaction id, I did not find mention of an<br /> algorithm for storing them, as it was done, for example, in MS SQL Server.<br /> What if instead of 2 fields (xmin and xmax) with a total length of 64 bits<br /> - use 1 field (let's call it xid) with a length of 64 bits in tuple header?<br /> In this field store the xid of the transaction that created the version. In<br /> this case, the new transaction in order to understand whether the read<br /> version is suitable for it or not, will have to read the next version as<br /> well. Those. The downside of such decision is of course an increase in I /<br /> O. Transactions will have to read the +1 version. On the plus side, the<br /> title of the tuple remains the same length.<br /><br /></blockquote><br />is 32 bit tid really problem? Why you need to know state of last 2^31<br />transactions? Is not problem in too low usage (or maybe too high overhead)<br />of VACUUM FREEZE.<br /><br /></blockquote><p><br />It certainly can be an issue for large and busy systems, that may need<br />anti-wraparoud vacuum every couple of days. If that requires rewriting a<br />couple of TB of data, it's not particularly nice. That's why 64-bit XIDs<br />were discussed repeatedly in the past, and it's likely to get even more<br />pressing as the systems get larger.<br /><br /></p><blockquote class="b4fd5cf2ec92bc68cb898700bb81355fwmi-quote">I am not sure if increasing this range can has much more fatal problems<br />(maybe later)<br /><br /></blockquote><p><br />Well, not fatal, but naive approaches can increase per-tuple overhead.<br />And we already have plenty of that, hence there were proposals to use<br />page epochs and so on.<br /><br /><br />regards<br /><br /></p><span class="c18e9d485856a85513717a5a5b59d3fewmi-sign">-- <br />Tomas Vondra <a href="http://www.2ndquadrant.com/">http://www.2ndQuadrant.com</a><br />PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services <br /></span></blockquote>