From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: On columnar storage |
Date: | 2015-06-14 17:41:26 |
Message-ID: | 20150614174125.GH133018@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund wrote:
> On 2015-06-11 20:03:16 -0300, Alvaro Herrera wrote:
> > Rewriter
> >
> > Parsing occurs as currently. During query rewrite, specifically at the
> > bottom of the per-relation loop in fireRIRrules(), we will modify the
> > query tree: each relation RTE containing a colstore will be replaced
> > with a JoinExpr containing the relation as left child and the colstore
> > as right child (1). The colstore RTE will be of a new RTEKind. For
> > each such change, all Var nodes that point to attnums stored in the
> > colstore will modified so that they reference the RTE of the colstore
> > instead (2).
>
> FWIW, I think this is a pretty bad place to tackle this. For one I think
> we shouldn't add more stuff using the rewriter unless it's clearly the
> best interface. For another, doing things in the rewriter will make
> optimizing things much harder - the planner will have to reconstruct
> knowledge which of the joins are column store joins and such.
What do you mean reconstruct? That bit will be explicit -- I'm thinking
the planner will have specialized bits to deal with such nodes, i.e. it
will know there's a one-to-one relationship between colstore tuples and
heap tuples, so it will know how to move nodes around.
Or at least, that's how I'm hoping it will be ...
> Why do you want to do things there?
Because I see no better place. Isn't the rewriter the place where we
modify the query tree, mostly?
Another choice I considered was subquery_planner: in the spot where
expand_inherited_tables() is called, add a new call to expand the RTEs
that correspond to tables containing stores. But I had second thoughts
because that function says "it's safe because it only adds baserels, not
joins", and I'm adding joins. I guess I could use a spot earlier than
wherever it is that joins are checked, but this planner code is
recursive anyway and for this I must do a single pass.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2015-06-14 17:41:45 | Re: 9.5 release notes |
Previous Message | Tom Lane | 2015-06-14 17:38:33 | Re: On columnar storage |