Re: Remaining beta blockers

* Kevin Grittner (kgrittn@ymail.com) wrote:
> Many people weighed in on the need to differentiate between an
> empty matview and one which has not been populated.  Many have also
> weighed in on the benefits of unlogged matviews.

Sure, I think I did that- we should be able to distinguish between those
two cases and unlogged matviews are great.

> > I see absolutely no reason to change my opinion on this.  Keeping
> > relisscannable state in the form of is-the-file-of-nonzero-size
> > is something we WILL regret
>
> ... or change in a subsequent major release.  I see no reason why
> using this technique now make it harder to do something else later.
> Could you elaborate on the technical challenges you see to doing
> so?

I've not followed this all that closely, to be honest, but I tend to
side with Tom on this, making PG depend on the file size for an
attribute of a relation is a bad idea.  For one thing, what happens when
an admin figures out that they can 'hack' the system to do what they
want by truncating that file?  Or we end up wanting to have that file be
non-zero and considered 'empty' later, but we don't want pg_upgrade
running around touching all of the existing files out there?

> I would guess that about half the use-cases for materialized views
> will stay with tables in spite of the added hassle, if they have to
> degrade performance by adding logging where they currently have
> none.

Life's tough.  There's quite a few things that I wish had made it into
9.3 which didn't.  One might also point out that a lot of individuals
may be, understandably, cautious about this new feature and not use it
in the first major rev it's released in anyway (I'm talking about
matviews entirely here..).  Basically, I don't believe we should be
acting like we've promised unlogged-matviews will be in 9.3 just because
it's been committed.

> > The way forward to unlogged matviews that behave the way Kevin
> > wants is to improve crash recovery so that we can update catalog
> > state after completing recovery, which is something there are
> > other reasons to want anyway.
>
> That would certainly be for the best.

Then let's forgo having this specific feature in 9.3 and implement it
correctly for 9.4.

> The hysteria and FUD about using the currently-supported technique
> for unlogged tables to implement unlogged matviews are very
> discouraging. 

Perhaps I'm all wet here, but it's not obvious to me that what's done
for unlogged tables really equates to what's being done here.

> And the notion that we would release a matview
> feature which allowed false results (in the form of treating a
> never-populated matview as a legal empty matview) is truly scary to
> me.  If we can't tell the difference between those two things, I
> don't think we should be releasing the feature.

I agree that it's important to distinguish the two.  I'm not sure that
I've heard anyone explicitly say otherwise..
Thanks,
    Stephen