On Sun, Apr 11, 2010 at 5:24 AM, Greg Smith <g...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
