> >> Aside from the convenience of the REFRESH functionality, are there any other >> factors I should consider? > An exclusive lock is taken on the materialized view during a REFRESH > operation, blocking an read or write queries attempted on them. You > can tackle this limitation in the upcoming 9.4 by using REFRESH > CONCURRENTLY, a unique index being necessary on the materialized view. > --
Yep. Thanks Michael. I was actually trying to say that I have no need for refresh functionality in this instance. :) - The table/views I need will be destroyed and recreated each night. - Refresh functionality isn’t helpful in this instance, as the underlying tables will also be destroyed - Crash recovery isn’t necessary So, in this scenario - will I get any benefit from a materialised view, that I wouldn't have from an unlogged table? Cheers
