Re: Remaining beta blockers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> In the interests of moving the discussion along, attached are
> draft patches to show what I think we should do in 9.3.  The
> first patch disables the unlogged-matviews feature at the user
> level (and perhaps could be reverted someday), while the second
> one moves scannability-state storage into a pg_class column.

I'm going to submit a modified version of the second patch today.
My biggest problems with it as it stands are the name chosen for
the new pg_class column, and the hard-coded assumption that this
relation-level flag is a good long-term indicator of whether all
connections find a matview to be scannable.  Scannability should
be abstracted to allow easy addition of other factors as we add
them.  Whether or not the "populated" state is in the catalog, it
is a serious mistake to conflate that with scannability.

Scannability will always be influenced by whether the matview has
been populated, but it is short-sighted not to draw a distinction
now, so that work people do in their applications is does not have
to be redone as we make scannability tests better.  Not to mention
the confusion factor of treating them as this patch does and then
trying to properly draw the distinction later.  IMV this patch, as
it stands, does much more to paint us into a corner regarding
future expansion than what came before.

As one example, I think it is highly desirable, long term, to allow
different sessions to set GUCs to different tolerances for old
data, and thus have different perspectives on whether a matview is
scannable; and this patch forces that to be the same for every
session.  The code I committed allows expansion in the direction of
different session perspectives on scannability, and the suggested
patch closes that door.

--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company