Re: GSoC - proposal - Materialized Views in PostgreSQL

On Sun, Apr 11, 2010 at 5:24 AM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> 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.

I think that one of the things that we need to get our hands around is
how we're going to distinguish the "snapshot" flavor of materialized
view from the "continuous update" flavor. By definition, the latter
will only ever be supportable for a fairly restricted subset of all
possible queries, and I am assuming that we will not want to decide
what the behavior is going to be based on the query but rather based
on what the user specifies. Anything else seems like it would be have
the potential for severe POLA violations. So we need to think now
about how we'll distinguish between the two flavors. I imagine some
sort of syntactic marker would be appropriate; not sure what.

Reading this thread, I'm starting to grow concerned that some people
may feel that manually refreshed materialized views are not even worth
bothering with, because (the argument goes) you could just use some
table and write a function that updates it. There's probably some
truth to that, but I guess my thought is that it would have some value
as a convenience feature; and eventually we might optimize it to the
point where it would make more sense to use the built-in feature
rather than rolling your own. However, if we're going to have
complaints that manually refreshed materialized views suck and we
should only ever support materialized views to the extent that we can
make them automatically update on-the-fly, then let's have those
complaints now before someone spends several months of their life on
the project only to be told that we don't want it. Let's be clear: I
think it's useful, but, if other people disagree, we need to iron that
out now.

...Robert