Re: hyrax vs. RelationBuildPartitionDesc

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: hyrax vs. RelationBuildPartitionDesc
Date: 2019-04-15 06:36:35
Message-ID: c5e975fc-ae5a-47a5-ffb7-a85c205cfdd5@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2019/04/14 0:53, Tom Lane wrote:
> Amit Langote <amitlangote09(at)gmail(dot)com> writes:
>> On Sat, Apr 13, 2019 at 4:47 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

Ah, that's right. It was just that you were replying to this:

Robert wrote:
> As a parenthetical note, I observe that relcache.c seems to know
> almost nothing about rd_partcheck. rd_partkey and rd_partdesc both
> have handling in RelationClearRelation(), but rd_partcheck does not,
> and I suspect that's wrong.

Maybe I just got confused.

> 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.

Makes sense.

> 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.

OK.

>>> 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.

Ah, yes. Actually, even a RANGE default partition that's the only
partition of its parent has NIL partition constraint.

Thanks,
Amit

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2019-04-15 06:37:07 Re: Mailing list not working
Previous Message Amit Langote 2019-04-15 06:22:08 Re: COLLATE: Hash partition vs UPDATE