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 →
-
Preserve intermediate .c files in coverage mode
- 4af3dda13601 9.3.0 cited