Tom Lane wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > > Tom Lane wrote: > >> Actually ... if you intend to allow column storage to work with inherited > >> tables (and if you don't, you'd better have a darn good reason why not), > >> I think you probably want to do this join insertion *after* inheritance > >> expansion, so you can join child column stores only to the appropriate > >> child heap table, and not to the entire inheritance tree. > > > Won't this cause issues to MergeAppend optimizations? > > Like what?
Well, as I understand, MergeAppend needs to know the sort order of the child node, right? But that's available only on the relation RTE, not on the colstore-join RTE. Though now that I think about it, maybe I can push that info from the relation RTE to the colstore-join RTE, since I know the ordering will be the same. > And if there are such issues, why do you think you wouldn't be > expected to solve them? Precisely. If I simply reject having column stores in partitioned tables, then I don't *need* to solve them. Later in the project, when some planner hacker decides to join, I can ask them for advice on how to tackle them. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
