Skip site navigation (1) Skip section navigation (2)

Re: Materialized views WIP patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <kgrittn(at)mail(dot)com>
Cc: "Marko Tiikkaja" <pgmail(at)joh(dot)to>, "Pgsql Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Materialized views WIP patch
Date: 2013-01-16 18:38:57
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-committerspgsql-hackers
"Kevin Grittner" <kgrittn(at)mail(dot)com> writes:
> Tom Lane wrote:
>> Surely that should fall out automatically given that the
>> dependency is properly expressed in pg_depend?

> The *definitions* sort properly, but what I'm trying to do is
> define them WITH NO DATA and load data after all the COPY
> statements for tables. If mva is referenced by mvb, the goal is the
> REFRESH mva, build its indexes before running REFRESH for mvb and
> building its indexes. To do things in any other order does't seem
> to me to leave things after restore in the same state they were in
> at the time of the dump.

Ah.  Can't you treat this using the same pg_dump infrastructure as
for the data for an ordinary table?  The dependencies made for the
TableDataInfo object might be a bit different, but after that it
seems like the sort logic ought to be happy.

> 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'm also wondering about locking issues there.  Obviously you don't
want more than one backend trying to rebuild the MV.

Do we really need unlogged MVs in the first iteration?  Seems like
that's adding a whole bunch of new issues, when you have quite enough
already without that.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Josh BerkusDate: 2013-01-16 19:12:07
Subject: Re: Materialized views WIP patch
Previous:From: Josh BerkusDate: 2013-01-16 18:00:22
Subject: Re: CF3+CF4 WAS: Parallel query execution

pgsql-committers by date

Next:From: Josh BerkusDate: 2013-01-16 19:12:07
Subject: Re: Materialized views WIP patch
Previous:From: Kevin GrittnerDate: 2013-01-16 16:48:17
Subject: Re: Materialized views WIP patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group