2013/5/17 Claudio Freire :
> On Fri, May 17, 2013 at 4:25 PM, Kevin Grittner wrote:
>
>>> (3) The count algorithm must be implemented in a way that understands
>>> MVCC internals: Reading the base tables must be done using a technique
>>> that reads all rows (i.e., also the ones not visible to th
Josh Berkus wrote:
> This sounds like a fairly good approach. It would require a
> couple of things though:
>
> 1) admins would need to be able to enable and disable incremental
> updating of matviews, so that if the creation of delta tables is
> bogging down writes, they can disable them tempor
Kevin,
> The count_t column saves us from having to scan foo for all the old
> val values. It does not require any scan of the entire bar
> matview. It allows us to zero in on exactly the right rows, and
> lets us know what needs doing.
This sounds like a fairly good approach. It would require
Nicolas Barbier wrote:
> 2013/5/17 Kevin Grittner :
>> Nicolas Barbier wrote:
>>
>>> Note that the basic count algorithm assumes real-serializable
>>> transactions for correctness. Example:
>
> [..]
>
>> Good point.
>>
>> It might be hard to detect when this type of race condition exists,
>> sinc
2013/5/17 Kevin Grittner :
> Nicolas Barbier wrote:
>
>> Note that the basic count algorithm assumes real-serializable
>> transactions for correctness. Example:
[..]
> Good point.
>
> It might be hard to detect when this type of race condition exists,
> since it could be hidden inside a functio
On Fri, May 17, 2013 at 4:25 PM, Kevin Grittner wrote:
>> (3) The count algorithm must be implemented in a way that understands
>> MVCC internals: Reading the base tables must be done using a technique
>> that reads all rows (i.e., also the ones not visible to the current
>> transaction), and the
Nicolas Barbier wrote:
> 2013/5/17 Kevin Grittner :
>
>> During calculation of the deltas to apply to the matviews, it must
>> be possible to query the referenced tables from the perspective of
>> both the "before" and "after" versions of the data.
>
> [..]
>
>> I don't think the process applying
2013/5/17 Kevin Grittner :
> During calculation of the deltas to apply to the matviews, it must
> be possible to query the referenced tables from the perspective of
> both the "before" and "after" versions of the data.
[..]
> I don't think the process applying the deltas needs to do
> anything u
Amit Kapila wrote:
> On Thursday, May 16, 2013 7:02 PM Kevin Grittner wrote:
>> Let's say there is a table and matview like this:
>
>> create table foo (fooid int primary key, val int not null);
>> create materialized view bar as select distinct val from foo;
>
>> Let's say there are millions of
Amit Kapila wrote:
> On Wednesday, May 15, 2013 1:22 AM Kevin Grittner wrote:
>
> Good explanation for understanding the initial concept of
> incremental update of matviews.
Thanks. This is one of those topics where it takes a lot of time
going over highly technical papers to really get your hea
On Thursday, May 16, 2013 7:02 PM Kevin Grittner wrote:
Josh Berkus wrote:
> Let's say there is a table and matview like this:
> create table foo (fooid int primary key, val int not null);
> create materialized view bar as select distinct val from foo;
> Let's say there are millions of rows in
On Wednesday, May 15, 2013 1:22 AM Kevin Grittner wrote:
Good explanation for understanding the initial concept of incremental update
of matviews.
> The original and modified versions of the relations (tables or
> other matviews) which define a matview must be available to
> calculate the matview
On Thu, May 16, 2013 at 8:33 PM, Kevin Grittner wrote:
> Robert Haas wrote:
>> Kevin Grittner wrote:
>>> We could drive the triggering of incremental maintenance off of the
>>> dependency information which is already stored, but for performance
>>> we probably want to add a new pg_class flag to
Robert Haas wrote:
> Kevin Grittner wrote:
>> We could drive the triggering of incremental maintenance off of the
>> dependency information which is already stored, but for performance
>> we probably want to add a new pg_class flag to indicate that the
>> relation is referenced by a matview defin
On Tue, May 14, 2013 at 3:52 PM, Kevin Grittner wrote:
> We could drive the triggering of incremental maintenance off of the
> dependency information which is already stored, but for performance
> we probably want to add a new pg_class flag to indicate that the
> relation is referenced by a matvie
I wrote:
> Let's say there is a table and matview like this:
>
> create table foo (fooid int primary key, val int not null);
> create materialized view bar as select distinct val from foo;
Some of the subsequent text doesn't make sense unless that
materialized view has an index, like this:
crea
Josh Berkus wrote:
> It's fairly common for matviews to be constructed such that
> updates to them are strictly appends. For example, a matview
> which has a daily summary would just get appended to each day,
> and existing rows would not change barring a major historical
> database cleanup.
>
>
Kevin,
It's fairly common for matviews to be constructed such that updates to
them are strictly appends. For example, a matview which has a daily
summary would just get appended to each day, and existing rows would not
change barring a major historical database cleanup.
It seems like we could ..
Merlin Moncure wrote:
> Kevin Grittner wrote:
>> Merlin Moncure wrote:
>>
>>> #1 issue I have with current matview functionality is locking.
>>> currently refresh takes out an access exclusive lock. so,
>>> question is, do you think your proposal will be such that it
>>> will no longer require
On Wed, May 15, 2013 at 11:33 AM, Kevin Grittner wrote:
> Merlin Moncure wrote:
>
>> #1 issue I have with current matview functionality is locking.
>> currently refresh takes out an access exclusive lock. so,
>> question is, do you think your proposal will be such that it will
>> no longer requi
Merlin Moncure wrote:
> #1 issue I have with current matview functionality is locking.
> currently refresh takes out an access exclusive lock. so,
> question is, do you think your proposal will be such that it will
> no longer require taking out full lock for refresh purposes
> (either increment
On Tue, May 14, 2013 at 2:52 PM, Kevin Grittner wrote:
> In surveying the literature on $subject, I find that most of the
> theoretical work related to how to incrementally update
> materialized views based on the matview declaration was published
> between 1988 and 1993. The best paper I have be
In surveying the literature on $subject, I find that most of the
theoretical work related to how to incrementally update
materialized views based on the matview declaration was published
between 1988 and 1993. The best paper I have been able to find on
the topic was published in ACM SIGMOD in 1993
23 matches
Mail list logo
