Another question: do we want to commit the code for creating unflattened hierarchy separately or along with partition-wise join?
On Fri, Dec 23, 2016 at 9:58 AM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Thu, Dec 22, 2016 at 10:52 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Wed, Dec 21, 2016 at 11:31 PM, Ashutosh Bapat >> <ashutosh.ba...@enterprisedb.com> wrote: >>> Given the scenario described above, it looks like we have to retain >>> partition hierarchy in the form of inheritance hierarchy in order to >>> implement partition-wise joins for multi-leveled partition tables. Is >>> that the right thing to do? PFA a patch retained by Amit Langote to >>> translate partition hierarchy into inheritance hierarchy. Is this >>> something on the right direction? >> >> I am not sure whether Amit's patch is the right way to go. I don't >> fully understand it, and I remember complaining about some aspects of >> it before, such as this unexplained and fairly random-looking >> exception: >> >> + /* >> + * Do not flatten the inheritance hierarchy if partitioned table, unless >> + * this is the result relation. >> + */ >> >> However, I think the overall idea of doing flattening later in the >> process for partitioned tables is probably correct. It's not that we >> shouldn't do flattening at all -- the final Plan shouldn't involve >> nested Append nodes -- but maybe we should delay it. Perhaps the Path >> tree retains the structure and the final Plan flattens it. > > While creating append paths we flatten any append paths added to the children. > >> We might >> consider doing that way for both inheritance trees and partitioning, >> just so we don't have two different code paths to validate. >> > > AFAIU the reason why we chose to flatten the inheritance hierarchy is > multiple inheritance. Since the same child can inherit from two > parents, in an unflattened version its paths would be included twice. > It would be clumsy to keep the inheritance unflattened but not include > a relation more than once in the final plan tree. > > However, for partitioned tables, we are guaranteed that there's only a > single parent and thus every child relation will be considered only > once. We will need separate code to handle (possible) multiple > inheritance and strictly single inheritance imposed by partitioning. > > -- > Best Wishes, > Ashutosh Bapat > EnterpriseDB Corporation > The Postgres Database Company -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
