Re: Materialized views WIP patch - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Materialized views WIP patch
Date
Msg-id CA+TgmoapxXwynTTboA=PAugb7y8=8YfJwNk3Ux9wBkJeuRuA6A@mail.gmail.com
Whole thread Raw
In response to Re: Materialized views WIP patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Materialized views WIP patch
List pgsql-hackers
On Wed, Jan 16, 2013 at 1:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Where I really need someone to hit me upside the head with a
>> clue-stick is the code I added to the bottom of RelationBuildDesc()
>> in relcache.c. The idea is that on first access to an unlogged MV,
>> to detect that the heap has been replaced by the init fork, set
>> relisvalid to false, and make the heap look normal again.
>
> Hmm.  I agree that relcache.c has absolutely no business doing that,
> but not sure what else to do instead.  Seems like it might be better
> done at first touch of the MV in the parser, rewriter, or planner ---
> but the fact that I can't immediately decide which of those is right
> makes me feel that it's still too squishy.

I think we shouldn't be doing that at all.  The whole business of
transferring the relation-is-invalid information from the relation to
a pg_class flag seems like a Rube Goldberg device to me.  I'm still
not convinced that we should have a relation-is-invalid flag at all,
but can we at least not have two?

It seems perfectly adequate to detect that the MV is invalid when we
actually try to execute a plan - that is, when we first access the
heap or one of its indexes.  So the bit can just live in the
file-on-disk, and there's no need to have a second copy of it in
pg_class.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: review: pgbench - aggregation of info written into log
Next
From: Andrew Dunstan
Date:
Subject: Re: review: pgbench - aggregation of info written into log