Re: Remaining beta blockers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Kevin Grittner <kgrittn(at)ymail(dot)com> writes:

>> The flip side of that is that it might be confusing to try
>> to explain why users should care which test they use before they
>> are capable of returning different results.
>
> That's a good point too, though; if they are returning the same
> thing right now, it's not very clear that users will pick the
> right test to make anyway.  Especially not if
> pg_relation_is_scannable() is a couple orders of magnitude more
> expensive, which it will be, cf my original complaint about
> pg_dump slowdown.

Since the patch we have floating around drops it, let's leave it
that way, in the interest of saving time getting to beta.  If it
was still there, I'd probably vote to leave it for the same reason.
It's pretty close to a toss-up at this point in terms of
cost/benefit, and that seems like the tie-breaker.

>> Also, rather than do the direct update to pg_class in pg_dump,
>> how would you feel about an ALTER MATERIALIZED VIEW option to
>> set the populated state?
>
> It seems a bit late to be adding such a thing;

No kidding.  The same could be said for the rest of this.  It was
all talked to death months ago before I posted a patch which was
proposed for commit.  All this eleventh hour drama bothers me.
I've always maintained we should add an ALTER capabilities for such
things once they are in the catalog.  A few days ago they weren't.
Now they are.

> moreover, how would you inject any data without doing something
> like what pg_upgrade is doing?

I wouldn't.  I'm talking about taking that code out of pg_upgrade
and putting it in the server under an ALTER command.  If the point
of moving the info to the catalog was to avoid hacks, it would be
nice not to add a hack like that in the process.

> I see no point in an ALTER command until there's some other
> SQL-level infrastructure for incremental matview updates.

It's only important to avoid having client code directly update
system tables, which I generally view as a worthwhile goal.

> In the context of pg_dump's binary upgrade option, I had thought
> of adding a new pg_upgrade_support function, but I saw that we
> already use direct pg_class updates for other nearby
> binary-upgrade hacking; so it didn't seem unreasonable to do it
> that way here.

In that case, I guess we might as well follow suit and do it the
way you have it for 9.3.

I didn't see anything I thought needed changing in your first patch
(to disable unlogged matviews), and my suggested changes to your
second patch (to move tracking of populated status to pg_class) are
just names, aliases, and comments.  I suggest you review my
proposed tweak to your patch and apply both with any final
polishing you feel are appropriate.

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