Re: [HACKERS] expanding inheritance in partition bound order

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] expanding inheritance in partition bound order
Дата
Msg-id CA+Tgmoafr=hUrM=cbx-k=BDHOF2OfXaw95HQSNAK4mHBwmSjtw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] expanding inheritance in partition bound order  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: [HACKERS] expanding inheritance in partition bound order  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Re: [HACKERS] expanding inheritance in partition bound order  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Список pgsql-hackers
On Tue, Aug 29, 2017 at 10:36 PM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] expanding inheritance in partition bound order
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] segment size depending *_wal_size defaults (wasincreasing the default WAL segment size)