Kevin Grittner <kgrittn@ymail.com> writes:
> 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.
[ raised eyebrow... ] There is certainly nothing about file-size-based
state that would particularly support per-session scannability
determination. If you want to call the pg_class column relispopulated
rather than relisscannable, I have no particular objection to that ---
but otherwise it sounds like you're moving the goalposts at the last
minute.
regards, tom lane
