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
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 |