Re: [HACKERS] GSoC - Materialized Views - is stale or fresh?

2010-06-14 Thread Josh Berkus
> At the risk of sounding obsessed, this is an area where predicate > locks might be usefully extended, if and when the serializable patch > makes it in. Yes, we see your patch in 9.1-first. ;-) -- -- Josh Berkus PostgreSQ

Re: [HACKERS] GSoC - Materialized Views - is stale or fresh?

2010-06-14 Thread Pavel Baroš
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, DE

Re: [HACKERS] GSoC - Materialized Views - is stale or fresh?

2010-06-14 Thread Kevin Grittner
Robert Haas wrote: > What Pavel's trying to do here is be smart about figuring out when > an MV needs to be refreshed. I'm pretty sure this is the wrong > way to go about it, but it seems entirely premature considering > that we don't have a working implementation of a *manually* > refreshed MV

Re: [HACKERS] GSoC - Materialized Views - is stale or fresh?

2010-06-14 Thread Robert Haas
On Mon, Jun 14, 2010 at 5:00 AM, Magnus Hagander wrote: > 2010/6/14 Greg Smith : >> Pavel Baros wrote: >>> >>> 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 cache

Re: [HACKERS] GSoC - Materialized Views - is stale or fresh?

2010-06-14 Thread Magnus Hagander
2010/6/14 Greg Smith : > Pavel Baros wrote: >> >> 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. > > An update in PostgreSQL is essentially an INSERT

Re: [HACKERS] GSoC - Materialized Views - is stale or fresh?

2010-06-13 Thread Greg Smith
Pavel Baros wrote: 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. An update in PostgreSQL is essentially an INSERT followed a later DELETE when VACUU

Re: [HACKERS] GSoC - Materialized Views - is stale or fresh?

2010-06-13 Thread Heikki Linnakangas
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 again

[HACKERS] GSoC - Materialized Views - is stale or fresh?

2010-06-13 Thread Pavel Baros
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 info

[HACKERS] GSoC - Materialized Views - is stale or fresh?

2010-06-13 Thread Pavel Baros
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 info