Re: matview scannability rehash (was Re: Drastic performance loss in assert-enabled build in HEAD)

Noah Misch <noah@leadboat.com> writes:
> On Wed, Apr 03, 2013 at 05:49:18PM -0400, Tom Lane wrote:
>> No.  This is an absolute disaster.  It's taking something we have always
>> considered to be an irrelevant implementation detail and making it into
>> user-visible DDL state, despite the fact that it doesn't begin to satisfy
>> basic transactional behaviors.  We *need* to get rid of that aspect of
>> things.  If you must have scannability state in version 0, okay, but
>> it has to be a catalog property not this.

> In large part, this ended up outside the catalogs due to key limitations of
> the startup process.

Yeah, I realize that there's no other (easy) way to make unlogged
matviews reset to an invalid state on crash, but that doesn't make this
design choice less of a disaster.  It boxes us into something that's
entirely unable to support transitions between scannable and unscannable
states by any means short of a complete rewrite of the matview contents;
which seems fundamentally incompatible with any sort of incremental
update scenario.  And I remain of the opinion that it's going to box us
into not being able to fix the problems because of pg_upgrade
on-disk-compatibility issues.  We will be far better off to drop
unlogged matviews until we can come up with a better design.  If that's
so far off that no one can see it happening, well, that's tough.
Leaving the door open for incremental maintenance is more important.

> A slight variation on the committed approach would be to add a "_scannable"
> relation fork.

Not very transaction-safe, I think (consider crash midway through a
transaction that adds or removes the fork), and in any case orders of
magnitude more expensive than looking at a pg_class field.  This really
needs to be catalog state, not filesystem state.
        regards, tom lane