On 5 March 2013 22:02, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> FWIW, my opinion is that doing anything like this in the planner is
> going to be enormously expensive. Index matching is already pretty
> expensive, and that has the saving grace that we only do it once per
> base relation. Your sketch above implies trying to match to MVs once
> per considered join relation, which will be combinatorially worse.
> Even with a lot of sweat over reducing the cost of the matching, it
> will hurt.
As we already said: no MVs => zero overhead => no problem. It costs in
the cases where time savings are possible and not otherwise. The type
of queries and their typical run times are different to the OLTP case,
so any additional planning time is likely to be acceptable. I'm sure
we can have a deep disussion about how to optimise the planner for
this; I'm pretty sure there are reasonable answers to the not-small
difficulties along that road.
Most importantly, I want to make sure we don't swing the door shut on
improvements here, especially if you (Tom) are not personally
convinced enough to do the work yourself.
Making transactional MVs work would be in part justified by the
possible existence of automatic lookaside planning, so yes, the two
things are not linked but certainly closely related.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
