Re: Materialized views WIP patch

Dimitri Fontaine <dimitri@2ndquadrant.fr>

From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Kevin Grittner <kgrittn@mail.com>, Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2012-11-16T13:13:43Z
Lists: pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> The documentation says that a materialized view is basically a
> create-table-as-select except that it remembers the query. Would you say
> that there is a compelling use case for this alone, or is this a
> building block for more sophisticated materialized view support (e.g.
> eager updating) later?

The implementation of the re-LOAD'ing command makes it already
worthwile. Bonus point if locking is limited to when the new content is
all computer and ready, but even without that, I want to have it. ;)

I'd bikeshed and prefer the UPDATE MATERIALIZED VIEW nsp.foo; of course.

The alternative is creating a view, a matching table and a stored
procedure that will implement the rebuilding, for each mat view you want
to have. So that's already a big step forward in my eyes.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Preserve intermediate .c files in coverage mode