Re: [HACKERS] advanced partition matching algorithm forpartition-wise join
От | Ashutosh Bapat |
---|---|
Тема | Re: [HACKERS] advanced partition matching algorithm forpartition-wise join |
Дата | |
Msg-id | CAFjFpRc9P0bx663B53LfJCi00vvwzYN9wev-HkLGXY+dHRds7A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] advanced partition matching algorithm forpartition-wise join (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Список | pgsql-hackers |
On Fri, Feb 9, 2018 at 11:26 AM, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote: > On 2018/02/09 14:31, Ashutosh Bapat wrote: >>> I also noticed that a later patch adds partsupfunc to PartitionScheme, >>> which the pruning patch needs too. So, perhaps would be nice to take out >>> that portion of the patch. That is, the changes to PartitionScheme struct >>> definition and those to find_partition_scheme(). >> >> I am not sure whether a patch with just that change and without any >> changes to use that member will be acceptable. So leaving this aside. > > I asked, because with everything that I have now changed in the partition > pruning patch, one would need to pass these FmgrInfo pointers down to > partition bound searching functions from the optimizer. If the changes to > add partsupfunc to the optimizer were taken out from your main patch, the > pruning patch could just start using it. For now, I'm making those > changes part of the pruning patch. That's fine. Someone's patch will be committed first and the other will just take out those changes. But I am open to separate those changes into other patch if a committer feels so. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
В списке pgsql-hackers по дате отправления: