Re: posgres 12 bug (partitioned table)

From: Pavel Biryukov <79166341370(at)yandex(dot)ru>
To: Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Amit Langote <amitlangote09(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: posgres 12 bug (partitioned table)
Date: 2021-04-22 04:30:41
Message-ID: 2755061619065272@mail.yandex.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

<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" &lt;andres(at)anarazel(dot)de&gt;:</div><blockquote><p>Hi,<br /><br />On 2021-04-21 17:38:53 -0400, Tom Lane wrote:</p><blockquote> Andres Freund &lt;<a href="mailto:andres(at)anarazel(dot)de" rel="noopener noreferrer">andres(at)anarazel(dot)de</a>&gt; writes:<br /> &gt; I don't really see us getting rid of something like ctid as a generic<br /> &gt; concept across AMs - there's just too many places that need a way to<br /> &gt; reference a specific tuple. However, I think we ought to change how much<br /> &gt; code outside of AMs know about what tids mean. And, although that's a<br /> &gt; significant lift on its own, we ought to make at least the generic<br /> &gt; 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>

Attachment Content-Type Size
unknown_filename text/html 2.6 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2021-04-22 05:00:14 Re: BUG #16972: parameter parallel_leader_participation's category problem
Previous Message Bharath Rupireddy 2021-04-22 01:02:57 Re: BUG #16972: parameter parallel_leader_participation's category problem

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-04-22 04:45:36 Re: Table refer leak in logical replication
Previous Message Kyotaro Horiguchi 2021-04-22 04:25:27 Re: Stale description for pg_basebackup