Re: Declarative partitioning - another take
От | Ashutosh Bapat |
---|---|
Тема | Re: Declarative partitioning - another take |
Дата | |
Msg-id | CAFjFpRfA7uiyvC7-nx6SiJeh6+y6FNz_nxNS99vei6xYHSa1Ew@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Declarative partitioning - another take (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: Declarative partitioning - another take
|
Список | pgsql-hackers |
> > With this patch, the mapping is created *only once* during > RelationBuildPartitionDesc() to assign canonical indexes to individual > list values. The partition OID array will also be rearranged such that > using the new (canonical) index instead of the old > catalog-scan-order-based index will retrieve the correct partition for > that value. > > By the way, I fixed one thinko in your patch as follows: > > - result->oids[i] = oids[mapping[i]]; > + result->oids[mapping[i]] = oids[i]; While I can not spot any problem with this logic, when I make that change and run partition_join testcase in my patch, it fails because wrong partitions are matched for partition-wise join of list partitions. In that patch, RelOptInfo of partitions are saved in RelOptInfo of the parent by matching their OIDs. They are saved in the same order as corresponding OIDs. Partition-wise join simply joins the RelOptInfos at the same positions from both the parent RelOptInfos. I can not spot an error in this logic too. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
В списке pgsql-hackers по дате отправления: