From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: move PartitionBoundInfo creation code |
Date: | 2018-11-08 03:59:27 |
Message-ID: | 56a26e7e-2a96-00e6-45c1-d20ecaafd99d@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018/11/08 11:48, Michael Paquier wrote:
>>> Thinking crazy, we could also create a subfolder partitioning/bounds/
>>> which includes three files with this refactoring:x
>>> - range.c
>>> - values.c
>>> - hash.c
>>> Then we keep partbounds.c which is the entry point used by partcache.c,
>>> and partbounds.c relies on the stuff in each other sub-file when
>>> building a strategy. This move could be interesting in the long term as
>>> there are comparison routines and structures for each strategy if more
>>> strategies are added.
>>
>> I'm not sure this is worthwhile. You'll create a bunch of independent
>> translation units in exchange for ...?
>
> That's the part about going crazy and wild on this refactoring. Not all
> crazy ideas are worth doing, still I like mentioning all possibilities
> so as we miss nothing in the review process.
It might be okay to split the big switch in partition_bounds_create() into
different functions for different partitioning methods for clarity as you
say, but let's avoid creating new files for range, list, and hash.
I will post an updated patch with that break down.
Thanks,
Amit
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2018-11-08 04:01:21 | Re: ATTACH/DETACH PARTITION CONCURRENTLY |
Previous Message | David Rowley | 2018-11-08 03:13:49 | Re: PostgreSQL Limits and lack of documentation about them. |