Merlin Moncure <mmonc...@gmail.com> wrote: > Kevin Grittner <kgri...@ymail.com> wrote: >> Merlin Moncure <mmonc...@gmail.com> wrote: >> >>> #1 issue I have with current matview functionality is locking. >>> currently refresh takes out an access exclusive lock. so, >>> question is, do you think your proposal will be such that it >>> will no longer require taking out full lock for refresh >>> purposes (either incremental or otherwise)? >> >> The right thread for *that* question is "Differential >> (transactional) REFRESH"; however, I might as well say here that >> I don't think we want to get rid of the (faster) version that >> just replaces the current heap when we add the (slower) option >> to REFRESH it transactionally. > > sorry, didn't notice that thread. agreed, that seems good > candidate for user input to refresh command to manage the > tradeoff. > > well, do you expect the application of differential refresh to be > automatic?
I expect considerable bikeshedding on this, but my preference would be to allow syntax for specifying which technique is desired on the REFRESH command, and in the absence of specification I would prefer that it default to the current technique for a matview which is not yet populated and the transactional technique for a populated matview. We could associate some property with the matview for default REFRESH technique, but I don't know whether that's worth the trouble. > lockless + differential refresh would be game changer in terms of > how I build up data for analytics. Yeah, it's definitely something I would have liked to have in the initial release, but I tried to keep the scope very limited given how little time there was left in the release cycle when I got a chance to start on it. Adding this seemed to be just a little too much. -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
