Re: On columnar storage

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

In response to

Responses

Browse pgsql-hackers by date

  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