Re: GSoC - Materialized Views - is stale or fresh?

From: Pavel Baroš <baros(dot)p(at)seznam(dot)cz>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: GSoC - Materialized Views - is stale or fresh?
Date: 2010-06-14 12:47:16
Message-ID: 4C1624D4.4040103@seznam.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas napsal(a):
> On 12/06/10 17:18, Pavel Baros wrote:
>> I am curious how could I solve the problem:
>>
>> During refreshing I would like to know, if MV is stale or fresh? And I
>> had an idea:
>>
>> In fact, MV need to know if its last refresh (transaction id) is older
>> than any INSERT, UPDATE, DELETE transaction launched against source
>> tables. So if MV has information about last (highest) xmin in source
>> tables, it could simply compare its own xmin to xmins (xmax for deleted
>> rows) from source tables and decide, if is stale or fresh.
>>
>> Whole realization could look like this:
>> 1. Make new column in pg_class (or somewhere in pg_stat* ?):
>> pg_class.rellastxid (of type xid)
>>
>> 2. After each INSERT, UPDATE, DELETE statement (transaction)
>> pg_class.rellastxid would be updated. That should not be time- or
>> memory- consuming (not so much) since pg_class is cached, I guess.
>
> rellastxid would have to be updated at every insert/update/delete. It
> would become a big bottleneck. That's not going to work.
>
> Why do you need to know if a MV is stale?
>

Sorry I did not mention it. If we knew MV is fresh, there is no neeed to
refresh MV and so it would prevent useless rebuilding of MV. So I
thought there is room for saving some work.

Anyway, I realized, this idea do not cover all the cases how to find out
MV is stale or fresh. For example, when updating a row of source table
of MV, that do not participate in MV, in that case refreshing of MV
would be useless too.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2010-06-14 12:55:04 Re: pg_archive_bypass
Previous Message Stephen Frost 2010-06-14 12:46:14 Re: [v9.1] add makeRangeTblEntry() into makefuncs.c