Re: counting algorithm for incremental matview maintenance

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Kevin Grittner <kgrittn(at)ymail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: counting algorithm for incremental matview maintenance
Date: 2013-05-15 17:20:30
Message-ID: CAHyXU0y+FaZ-GkghpffoRXWR03oKOjy-4jk0zwJGLoyWsUDMYw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 15, 2013 at 11:33 AM, Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)com> 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 incremental or otherwise)?
>
> The right thread for *that* question is "Differential
> (transactional) REFRESH"; however, I might as well say here that I
> don't think we want to get rid of the (faster) version that just
> replaces the current heap when we add the (slower) option to
> REFRESH it transactionally.

sorry, didn't notice that thread. agreed, that seems good candidate
for user input to refresh command to manage the tradeoff.

well, do you expect the application of differential refresh to be
automatic? lockless + differential refresh would be game changer in
terms of how I build up data for analytics.

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2013-05-15 17:30:24 Re: commit fest schedule for 9.4
Previous Message Kevin Grittner 2013-05-15 16:33:11 Re: counting algorithm for incremental matview maintenance