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
