On Tue, Feb 6, 2018 at 3:25 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > > Agreed. partition.c has gotten quite big and actually more than half of > the code that this patch adds really seems to belong outside of it. > >> And it seems to me that the code you're adding >> here is really quite similar to what we've already got in that >> directory -- for example, predtest.c, which currently does partition >> pruning, lives there; so does clauses.c, whose evaluate_expr facility >> this patch wants to use; so does relnode.c, which the other patches >> modify; and in general this looks an awful lot like other optimizer >> logic that decomposes clauses. I'm open to other suggestions but I >> don't think adding all of this directly into partition.c is a good >> plan. > > Agreed. > > A partprune.c in the optimizer's util directory seems like a good place.
partprune.c looks to much tied to one feature. I am sure that the functions used for partition pruning can be used by other optimizations as well. partition.c seems to have two kinds of functions 1. that build and manage relcache, creates quals from bounds etc. which are metadata management kind 2. partition bound comparison functions, and other optimizer related functions. May be we should divide the file that way. The first category code remains in catalog/ as it is today. The second catagory functions move to optimizer/. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
