From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: hyrax vs. RelationBuildPartitionDesc
Date: Sat, 13 Apr 2019 11:53:39 -0400
Message-ID: <19210.1555170819@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+HiwqF=toO_==HRN6FDXSZE4DExo+PxX3xPNuBs6UAdF3WLPQ@mail.gmail.com>
References: <CA+TgmoY3bRmGB6-DUnoVy5fJoreiBJ43rwMrQRCdPXuKt4Ykaw@mail.gmail.com>
<20190313164232.GA5270@alvherre.pgsql>
<CA+Tgmoabw8KW9rx6ThnUTR_ofJC8GwVaC+XMe7HkZvsG7J1rvA@mail.gmail.com>
<7448.1552497345@sss.pgh.pa.us>
<7961.1552498252@sss.pgh.pa.us>
<CA+TgmoaZ021fRZawzU_gozwgHMo-tXJc12uf3MJoA6k=HZsLJA@mail.gmail.com>
<10788.1552501588@sss.pgh.pa.us>
<CA+TgmoYd3vqd26RiT4sp7Mez3oQf-AxAzdBpEeTyCNF-7OchhA@mail.gmail.com>
<12316.1552504492@sss.pgh.pa.us>
<CA+TgmoacZD_WWWQ+_Fx93rGeSri=rzXO1SQ7XbW1BSns8DCh5Q@mail.gmail.com>
<389.1555098439@sss.pgh.pa.us>
<CA+HiwqF=toO_==HRN6FDXSZE4DExo+PxX3xPNuBs6UAdF3WLPQ@mail.gmail.com>
Amit Langote <amitlangote09@gmail.com> writes:
> On Sat, Apr 13, 2019 at 4:47 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I concluded that that's not parenthetical but pretty relevant...
> Hmm, do you mean we should grow the same "keep_" logic for
> rd_partcheck as we have for rd_partkey and rd_partdesc? I don't see
> it in the updated patch though.
No, the "keep_" stuff is only necessary when we're trying to preserve
data structures in-place, which is only important if non-relcache
code might be using pointers to it. Since rd_partcheck is never
directly accessed by external code, only copied, there can't be any
live pointers to it to worry about. Besides which, since it's load
on demand rather than something that RelationBuildDesc forces to be
valid immediately, any comparison would be guaranteed to fail: the
field in the new reldesc will always be empty at this point.
Perhaps there's an argument that it should be load-immediately not
load-on-demand, but that would be an optimization not a bug fix,
and I'm skeptical that it'd be an improvement anyway.
Probably this is something to revisit whenever somebody gets around to
addressing the whole copy-vs-dont-copy-vs-use-a-refcount business that
we were handwaving about upthread.
>> I also cleaned up the problem the code had with failing to distinguish
>> "partcheck list is NIL" from "partcheck list hasn't been computed yet".
>> For a relation with no such constraints, generate_partition_qual would do
>> the full pushups every time.
> Actually, callers must have checked that the table is a partition
> (relispartition).
That does not mean that it's guaranteed to have any partcheck constraints;
there are counterexamples in the regression tests. It looks like the main
case is a LIST-partitioned table that has only a default partition.
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-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, amitlangote09@gmail.com, robertmhaas@gmail.com, alvherre@2ndquadrant.com, Langote_Amit_f8@lab.ntt.co.jp, pgsql-hackers@lists.postgresql.org
Subject: Re: hyrax vs. RelationBuildPartitionDesc
In-Reply-To: <19210.1555170819@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