On Mon, Mar 8, 2021 at 9:53 PM Andy Fan <zhihui.fan1...@gmail.com> wrote:
> On Mon, Mar 8, 2021 at 8:42 PM Amit Langote <amitlangot...@gmail.com> wrote:
>> On Mon, Mar 8, 2021 at 8:39 PM Andy Fan <zhihui.fan1...@gmail.com> wrote:
>> > On Mon, Mar 8, 2021 at 3:43 PM Andy Fan <zhihui.fan1...@gmail.com> wrote:
>> >> My point below is a bit off-topic, but I want to share it here.  Since
>> >> we implement a partitioned table in PG with the inherited class, it has 
>> >> much
>> >> more flexibility than other databases.  Like in PG,  we allow different 
>> >> partitions
>> >> have different physical order,  different indexes,  maybe different index 
>> >> states.
>> >> that would cause our development work hard in many places and cause some
>> >> runtime issues as well (like catalog memory usage),  have we discussed
>> >> limiting some flexibility so that we can have better coding/running 
>> >> experience?
>> >> I want to do some research in this direction, but it would be better that 
>> >> I can
>> >> listen to any advice from others.  More specifically, I want to reduce 
>> >> the memory
>> >> usage of Partitioned table/index as the first step.  In my testing, each 
>> >> IndexOptInfo
>> >> will use 2kB memory in each backend.
>> >
>> >
>> > As for the compatible issue,  will it be ok to introduce a new  concept 
>> > like "
>> > CREATE TABLE p (a int) partitioned by list(a) RESTRICTED".  We can add 
>> > these
>> > limitation to restricted partitioned relation only.
>>
>> I think you'd agree that the topics you want to discuss deserve a
>> separate discussion thread.  You may refer to this discussion in that
>> new thread if you think that your proposals can solve the problem
>> being discussed here more generally, which would of course be great.
>
> Sure, I can prepare more data and start a new thread for this.

Great, thanks.

-- 
Amit Langote
EDB: http://www.enterprisedb.com


Reply via email to