From: Pavel Biryukov <79166341370@yandex.ru>
To: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Amit Langote <amitlangote09@gmail.com>
Cc: David Steele <david@pgmasters.net>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: posgres 12 bug (partitioned table)
Date: Thu, 22 Apr 2021 07:30:41 +0300
Message-ID: <2755061619065272@mail.yandex.ru> (raw)
In-Reply-To: <20210421214818.2ylmenjtu6gsyqx7@alap3.anarazel.de>
References: <407111603806900@mail.yandex.ru>
<CA+HiwqFjEim_RMCiaFxA4nUx00o3auXKPy-OsOcog+chg5K-zA@mail.gmail.com>
<cd492dbd-a0ba-4790-bcf7-c4af2d2dc8d1@pgmasters.net>
<CA+HiwqG7qhKJnFpZOqyrFngqcMzja+p=gssMK=73b+-BZffxqw@mail.gmail.com>
<CA+HiwqHqnC=A9a+=F-k8J=JV-EKKt3vTgxq01=9af-0HE045NQ@mail.gmail.com>
<793243.1619032209@sss.pgh.pa.us>
<20210421195904.kaa74iovl6okscjg@alap3.anarazel.de>
<801096.1619038302@sss.pgh.pa.us>
<20210421211239.o7j5cz4wjvlhwcam@alap3.anarazel.de>
<804629.1619041133@sss.pgh.pa.us>
<20210421214818.2ylmenjtu6gsyqx7@alap3.anarazel.de>
<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> </div><div> </div><div>22.04.2021, 00:48, "Andres Freund" <andres@anarazel.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@anarazel.de" rel="noopener noreferrer">andres@anarazel.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>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: 79166341370@yandex.ru, andres@anarazel.de, tgl@sss.pgh.pa.us, amitlangote09@gmail.com, david@pgmasters.net, pgsql-bugs@lists.postgresql.org
Subject: Re: posgres 12 bug (partitioned table)
In-Reply-To: <2755061619065272@mail.yandex.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox