On 14 June 2013 17:05, Kevin Grittner <kgri...@ymail.com> wrote: > Attached is a patch for REFRESH MATERIALIZED VIEW CONCURRENTLY for > 9.4 CF1. The goal of this patch is to allow a refresh without > interfering with concurrent reads, using transactional semantics.
Is there a reason to keep the non-concurrent behaviour? Anybody that wants to explicitly lock should just run a LOCK statement. Can't we treat behaviour when fully locked as an optimisation, so we can just do the right thing without extra thought and keywords? > It is my hope to get this committed during this CF to allow me to > focus on incremental maintenance for the rest of the release cycle. Incremental maintenance will be very straightforward using the logical changeset extraction code Andres is working on. Having two parallel mechanisms for changeset extraction in one release seems like a waste of time. Especially when one is known to be better than the other already. Given that we also want to do concurrent CLUSTER and ALTER TABLE ... SET TABLESPACE using changeset extraction I think its time that discussion happened on hackers. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
