Re: [HACKERS] path toward faster partition pruning
| От | Alvaro Herrera |
|---|---|
| Тема | Re: [HACKERS] path toward faster partition pruning |
| Дата | |
| Msg-id | 20171229130213.htk7pn5vfercayxz@alvherre.pgsql обсуждение исходный текст |
| Ответ на | Re: [HACKERS] path toward faster partition pruning (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
| Ответы |
Re: [HACKERS] path toward faster partition pruning
|
| Список | pgsql-hackers |
I happened to notice that Ashutosh's patch series at https://www.postgresql.org/message-id/CAFjFpReJhFSoy6DqH0ipFSHd=sLNEkSzAtz4VWCaS-w2jZL=uw@mail.gmail.com has a 0001 patch that modifies the partition_bound_cmp stuff too. Are those conflicting? Ashutosh's commit message: Modify bound comparision functions to accept members of PartitionKey Functions partition_bound_cmp(), partition_rbound_cmp() and partition_rbound_datum_cmp() are required to merge partition bounds from joining relations. While doing so, we do not have access to the PartitionKey of either relations. So, modify these functions to accept only required members of PartitionKey so that the functions can be reused for merging bounds. Amit's: Some interface changes for partition_bound_{cmp/bsearch} Introduces a notion of PartitionBoundCmpArg, which replaces the set of arguments void *probe and bool probe_is_bound of both partition_bound_cmp and partition_bound_bsearch. It wasn't possible before to specify the number of datums when a non-bound type of probe is passed. Slightly tweaking the existing interface to allow specifying the same seems awkward. So, instead encapsulate that into PartitionBoundCmpArg. Also, modify partition_rbound_datum_cmp to compare caller-specifed number of datums, instead of key->partnatts datums. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: