From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Amit Langote <amitlangote09@gmail.com>
Cc: David Steele <david@pgmasters.net>
Cc: Pavel Biryukov <79166341370@yandex.ru>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: posgres 12 bug (partitioned table)
Date: Wed, 21 Apr 2021 17:38:53 -0400
Message-ID: <804629.1619041133@sss.pgh.pa.us> (raw)
In-Reply-To: <20210421211239.o7j5cz4wjvlhwcam@alap3.anarazel.de>
References: <20200812162718.ycxrktzoe6rpdy5k@alap3.anarazel.de>
<CA+HiwqEGgy8x5M2dotzH7HSd0v+byyJXGU8S+d5NFnrOBiTZDA@mail.gmail.com>
<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>
Andres Freund <andres@anarazel.de> writes:
> On 2021-04-21 16:51:42 -0400, Tom Lane wrote:
>> Hmm, I'd have thought that ctid would be very high on the list of
>> things we don't want to assume are the same for all AMs. Admittedly,
>> refactoring that is going to be a large pain in the rear, but ...
> I don't really see us getting rid of something like ctid as a generic
> concept across AMs - there's just too many places that need a way to
> reference a specific tuple. However, I think we ought to change how much
> code outside of AMs know about what tids mean. And, although that's a
> significant lift on its own, we ought to make at least the generic
> representation variable width.
It seems like it might not be that hard to convert ctid generically
into a uint64, where heaps and heap-related indexes only use 6 bytes
of it. Variable-width I agree would be a very big complication added
on top, and I'm not quite convinced that we need it.
> Not fully responsive to this: I've previously wondered if we ought to
> handle tableoid at parse-analysis or expression simplification time
> instead of runtime. It's not really something that needs runtime
> evaluation. But it's also not clear it's worth changing anything...
If you do "RETURNING tableoid" in DML on a partitioned table, or on a
traditional-inheritance hierarchy, you get the OID of the particular
partition that was touched (indeed, that's the whole point of the
feature, IIRC). Don't really see how that could be implemented
earlier than runtime. Also don't see where the win would be, TBH.
regards, tom lane
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: tgl@sss.pgh.pa.us, andres@anarazel.de, amitlangote09@gmail.com, david@pgmasters.net, 79166341370@yandex.ru, pgsql-bugs@lists.postgresql.org
Subject: Re: posgres 12 bug (partitioned table)
In-Reply-To: <804629.1619041133@sss.pgh.pa.us>
* 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