<div>Hi guys,</div><div> </div><div>Are you going to completely remove xmin from partitioned tables? So it will not work in <em>select ..., xmin from partitioned_table ?</em></div><div> </div><div>For us as users of Postgres (not knowing internal details) it is strange that there are some problems with getting current transaction and saving it as usual to xmin...</div><div> </div><div>What about first adding a "rowversion" type like in SQL Server for optimistic concurrency?</div><div> </div><div>I would remind that many code use xmin and would no be able to work with partitioned table...</div><div><div><a href="https://www.npgsql.org/efcore/modeling/concurrency.html" rel="noopener noreferrer" target="_blank">https://www.npgsql.org/efcore/modeling/concurrency.html</a></div><div> </div></div><div> </div><div>-- <br />С уважением, Павел</div><div> </div><div> </div><div> </div><div>22.04.2021, 00:48, "Andres Freund" <andres(at)anarazel(dot)de>:</div><blockquote><p>Hi,<br /><br />On 2021-04-21 17:38:53 -0400, Tom Lane wrote:</p><blockquote> Andres Freund <<a href="mailto:andres(at)anarazel(dot)de" rel="noopener noreferrer">andres(at)anarazel(dot)de</a>> writes:<br /> > I don't really see us getting rid of something like ctid as a generic<br /> > concept across AMs - there's just too many places that need a way to<br /> > reference a specific tuple. However, I think we ought to change how much<br /> > code outside of AMs know about what tids mean. And, although that's a<br /> > significant lift on its own, we ought to make at least the generic<br /> > representation variable width.<br /><br /> It seems like it might not be that hard to convert ctid generically<br /> into a uint64, where heaps and heap-related indexes only use 6 bytes<br /> of it.</blockquote><p><br />Yep.<br /><br /> </p><blockquote> Variable-width I agree would be a very big complication added on top,<br /> and I'm not quite convinced that we need it.</blockquote><p><br />I can see three (related) major cases where variable width tids would be<br />quite useful:<br />1) Creating an index-oriented-table AM would harder/more<br /> limited with just an 8 byte tid<br />2) Supporting "indirect" indexes (i.e. indexes pointing to a primary<br /> key, thereby being much cheaper to maintain when there are updates),<br /> would require the primary key to map to an 8 byte integer.<br />3) Global indexes would be a lot easier if we had variable width tids<br /> (but other ways of addressing the issue are possible).<br /><br />Greetings,<br /><br />Andres Freund</p></blockquote>