Kevin Grittner <kgri...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers