From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: why doesn't DestroyPartitionDirectory hash_destroy? |
Date: | 2019-03-14 17:16:01 |
Message-ID: | 5230.1552583761@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Agreed, but the comments in this area are crap.
Actually, now that I've absorbed a bit more about 898e5e329,
I don't like very much about it at all. I think having it
try to hang onto pointers into the relcache is a completely
wrongheaded design decision, and the right way for it to work
is to just copy the PartitionDescs out of the relcache so that
they're fully owned by the PartitionDirectory. I don't see
a CopyPartitionDesc function anywhere (maybe it's named something
else?) but it doesn't look like it'd be hard to build; most
of the work is in partition_bounds_copy() which does exist already.
Also, at least so far as the planner's usage is concerned, claiming
that we're saving something by not copying is completely bogus,
because if we look into set_relation_partition_info, what do we
find but a partition_bounds_copy call. That wouldn't be necessary
if we could rely on the PartitionDirectory to own the data structure.
(Maybe it's not necessary today. But given what a house of cards
this is, I wouldn't propose ripping it out, just moving it into
the PartitionDirectory code.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2019-03-14 17:18:50 | Re: hyrax vs. RelationBuildPartitionDesc |
Previous Message | Tom Lane | 2019-03-14 16:56:42 | Re: why doesn't DestroyPartitionDirectory hash_destroy? |