From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: expanding inheritance in partition bound order |
Date: | 2017-08-30 03:03:34 |
Message-ID: | CA+Tgmoafr=hUrM=cbx-k=BDHOF2OfXaw95HQSNAK4mHBwmSjtw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 29, 2017 at 10:36 PM, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> I keep having the feeling that this is a big patch with a small patch
>> struggling to get out. Is it really necessary to change
>> RelationGetPartitionDispatchInfo so much or could you just do a really
>> minimal surgery to remove the code that sets the stuff we don't need?
>> Like this:
>
> Sure, done in the attached updated patch.
On first glance, that looks pretty good. I'll have a deeper look
tomorrow. It strikes me that if PartitionTupleRoutingInfo is an
executor structure, we should probably (as a separate patch) relocate
FormPartitionKeyDatum and get_partition_for_tuple to someplace in
src/backend/executor and rename the accordingly; maybe it's time for
an execPartition.c? catalog/partition.c is getting really bug, so
it's not a bad thing if some of that stuff gets moved elsewhere. A
lingering question in my mind, though, is whether it's really correct
to think of PartitionTupleRoutingInfo as executor-specific. Maybe
we're going to need that for other things too?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-08-30 03:52:26 | Re: segment size depending *_wal_size defaults (was increasing the default WAL segment size) |
Previous Message | Amit Langote | 2017-08-30 02:36:19 | Re: expanding inheritance in partition bound order |