From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Greg Stark <stark(at)mit(dot)edu>, Andres Freund <andres(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Remaining beta blockers |
Date: | 2013-05-05 15:20:53 |
Message-ID: | 2602.1367767253@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kevin Grittner <kgrittn(at)ymail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2013-05-05 15:51:37 | Re: 9.3 release notes suggestions |
Previous Message | Kevin Grittner | 2013-05-05 14:20:15 | Re: Remaining beta blockers |