On 5 March 2013 22:02, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
