Re: matview niceties: pick any two of these three - Mailing list pgsql-hackers

Kevin Grittner <kgrittn@ymail.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The current matview design gets around this problem by requiring
>> that transition between scannable and unscannable states involve
>> a complete table rewrite, and thus the transactionality issue can
>> be hidden behind a transactional update of the matview's
>> pg_class.relfilenode field.� IMO, that is obviously a dead-end
>> design, because we are going to want scannability status updates
>> associated with partial updates of the matview's contents.

> I don't think the change between populated and non-populated needs
> to change without a new heap being swapped in.

I think you are using the distinction between "populated" and
"scannable" to dodge the issue.  My point is that whenever we add some
better control over whether matviews are considered too-stale-to-use,
it is going to be important that the staleness state can be changed, in
either direction, without a full rewrite of the matview's contents.
Whether you call that "populated", or "scannable", or "stale", or "warm
fuzzy" doesn't matter to me.  If we can't do that then the feature is
not actually going to be of any great use.

And I want such updates to be transactional, because they'll very likely
be connected to transactional updates of the matview's contents.
So I continue to maintain that the current design is a dead end.

> We'll get into all
> kinds of design trouble if we conflate these two separate concepts.

Perhaps I still don't understand what useful distinction is there.
If there is a critical distinction, why is the current patch exposing
only one state value to users?

> I could probably add a hundred other desirable properties for a
> materialized view implementation; I was trying to list the ones
> which were still up-for-grabs for the initial 9.3 implementation. 
> If we want to make progress on catching up to other major databases
> on this, it will take progress in many releases; and every one of
> those will lack something that someone wants.� OK, a lot of things
> that a lot of people want.� But if we can't commit something that
> is less than complete or less than perfect to make incremental
> change, we're not going to be getting anywhere very fast.

Yes, exactly.  I am not sure why you are so desperate to have unlogged
matviews in 9.3 that you are willing to risk finding yourself boxed in
and unable to make future improvements that everybody agrees are useful.
ISTM that plain matviews are a perfectly good first-cut feature and we
can add unlogged ones whenever we can think of a better way to do it.

> If I thought that the current hack for tracking the populated state
> would be permanent, or that it would be so hard to replace in a
> later release that it would impede further development, I would be
> the first one to rip it out. I haven't been able to see such a
> risk, and nobody has adequately explained where they think the risk
> lies.

You can't update that state transactionally, and you can't update it
without a complete rewrite.  The only solutions you've offered to that
are devices Rube Goldberg would be proud of (not that the code wouldn't
fill his heart with joy as it is).  This is not a good place to be for
a first-cut implementation, at least not if we don't want to find
ourselves needing to make a representation change that pg_upgrade can't
readily cope with.

The long and the short of it is this: having unlogged matviews in 9.3
is not worth taking that risk for.  IMO anyway.

> I will certainly go along with the consensus, but from my
> perspective, living with the current hack for determining whether a
> matview has been populated is worth the benefit of having unlogged
> matviews in 9.3.� I don't expect that hack to be viable for more
> that one or two releases; I just think that it's a practical matter
> of working with the tools we have *now* for unlogged relations to
> try to create a new type of unlogged relation.

If you yourself admit that this hack has got a very short life
expectancy, why are you so willing to buy into the assumption that
you can get rid of it readily?  I do not grant that assumption,
and I'm not sure how come you think that hacking pg_upgrade to the point
of being able to get rid of it will be zero-cost, or even acceptable
to the community at all.
        regards, tom lane