On Fri, Apr 05, 2013 at 11:17:30AM +0200, Nicolas Barbier wrote: > 2013/4/5 Noah Misch <n...@leadboat.com>: > > On Thu, Apr 04, 2013 at 12:28:01PM +0200, Nicolas Barbier wrote: > >> +1. Having unlogged matviews without having incremental updates yet, > >> isn't super useful anyway. > > > > I would have surmised the opposite: since an unlogged MV requires a full > > refresh at unpredictable moments, logged MVs will be preferred where a > > refresh > > is prohibitively expensive. > > That sounds like a good reason to choose your matview to be logged indeed. > > I.e., very expensive to rebuild → choose logged > > The opposite is also true: If your matview is not so expensive to > rebuild, why would it matter that much if it is logged? (Rebuilding > would be a tad slower, but it is not that slow to start with, so who > cares?) > > I.e., not so expensive to rebuild → logged or unlogged are fine > > This would mean “always choose logged,” except for the restricted case > of “incremental updates of a matview that is not so expensive to > rebuild” that I describe next:
Cheap is good, but cheaper is better. Since a refresh locks out readers, mild wins do count. > > Why might unlogged-MV applications desire incremental updates more acutely > > than logged-MV applications? > > My reasoning was more like: If you have incremental updates, there > will probably be some overhead linked to executing any transaction > that updates the base tables, namely for storing the changesets > somewhere. I imagined it could at least be this storing of changesets > that one would want to be unlogged, lest it slowing down the commit of > most transactions that don’t even touch the matview. That's a good point. However, the same holds when refreshing a logged MV, especially at wal_level > minimal. The refresh exerts pressure on the WAL stream, likely delaying other WAL-using transactions. > As a sidenote, I see two ways to avoid storing changesets as part of a > commit that changes the base tables. Choosing any of those would > invalidate my previous logic, and even more diminish the need for > unlogged matviews: Regardless of the change storage method, actually applying incremental changes to a logged MV will require WAL. UNLOGGED MVs will stay relevant. -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
