Re: GSoC - proposal - Materialized Views in PostgreSQL

Robert Haas wrote:
> I also think that you're underestimating the number of problems that
> will have to be solved to get this done. It's going to take some
> significant work - both design work and coding work - to figure out
> how this should integrate into the rest of the system. (What should
> be the value of pg_class.relkind? Where should the node
> representation of the snapshot query be stored? And did we handle all
> of those OID dependencies correctly?)
>

I don't think I'm underestimating all that, but I suspect Pavel is by a
considerable amount. This is why I've been suggesting that a GSoC scope
here might just be wrestling with this area of the problem for the whole
summer--not even getting into updates beyond a completely trivial
implementation, if any at all. Things like "handle OID dependencies"
are definitely not on the fun side of the development work that people
tend to think about in advance.

> Where I can see this possibly falling down (other than being just too
> much work for a relative PostgreSQL novice to get it done in one
> summer) is if there are concerns about it being incompatible with
> incrementally-updated views. I imagine that we're going to want to
> eventually support both, so we need to make sure that this
> implementation doesn't box us into a corner.

Exactly my concern; comitting this part without knowing how that's later
going to fit into place strikes me the sort of the thing this project
doesn't like to do. The alternate approach of starting with the update
machinery is less likely IMHO to get stuck wondering if there's a future
blind spot coming or not, since you'd be building from the bottom up
starting with the hardest parts.

From the rest of your comments, I'm comfortable that you're in sync
with the not necessarily obvious risky spots here I wanted to raise
awareness of. It's unreasonable to expect we'll have exactly the same
priorities here, and I doubt it's useful to debate how I perceive the
merit of various development subsets here compared to yourself. I don't
think it's really important whether anyone agrees with me or not about
exactly the value of a full table lock implementation. The main thing
I'm concerned about is just that it's noted as a known risky part, one
that could end up blocking the project's ability to commit even a subset
of the proposed patch here.

--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.us