Re: GSoC - proposal - Materialized Views in PostgreSQL

2010/4/12 Robert Haas <robertmhaas(at)gmail(dot)com>:
> 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

I thing so manually refreshed materialized views has sense. It is
similar to replication - there was replications like slony, but for
some people is more important integrated replication in 9.0. More -
manually refreshed (periodically refreshed) views can share lot if
infrastructure with dynamically actualised views. I am sure so
dynamical materialised views is bad task for GSoC - it is too large,
too complex. Manually refreshed views is adequate to two months work
and it has sense.

Regards
Pavel Stehule

>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>