From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: On columnar storage |
Date: | 2015-06-14 17:54:27 |
Message-ID: | 20150614175427.GI133018@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> I wrote:
> > Another model that could be followed is expansion of inheritance-tree
> > references, which happens early in the planner.
>
> 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?
I guess we could have the join be of a new type that's transparent to
such optimizations but, you see, that seems complicated enough that I
want to avoid that ...
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-06-14 18:01:16 | Re: On columnar storage |
Previous Message | Tom Lane | 2015-06-14 17:47:54 | Re: On columnar storage |