From: | Christopher Jackson <crjackso(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | bricklen <bricklen(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org list" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Slow Count-Distinct Query |
Date: | 2014-04-02 04:54:02 |
Message-ID: | CAN81C19ZLf9C5rJVVY8ijfDLYhxUqC3SBUcdWTPe+ASQJbmZyw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi Bricklen,
Thanks again for the feedback. The concurrent refresh sounds cool. I
just saw the 9.4 release is tentatively scheduled for later this year. Do
you know what people have been doing for view refreshes in the meantime?
Thanks
On Tue, Apr 1, 2014 at 11:48 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com>wrote:
> On Wed, Apr 2, 2014 at 1:22 PM, Christopher Jackson <crjackso(at)gmail(dot)com>
> wrote:
> >
> > Hi Bricklen,
> >
> > Thanks for the feedback. I'll play around with materialized views.
> My
> > understanding is they have to be manually triggered for refresh
> Yep.
>
> > and there's an exclusive lock on the view while the refresh is taking
> place. Is this
> > your understanding as well?
> Re-yep.
>
> > I'm using PG 9.3.3. If this is true, I'm
> > curious what clever ways people have come up with to mitigate any issues
> > with the lock.
> Kevin Grittner has implemented REFRESH MATERIALIZED VIEW CONCURRENTLY
> in 9.4. A unique index is needed on the materialized view as well to
> authorize this concurrent operation. It has the merit to allow SELECT
> operations on the matview during the refresh.
> --
> Michael
>
From | Date | Subject | |
---|---|---|---|
Next Message | Alexey Klyukin | 2014-04-02 09:38:57 | Re: Why shared_buffers max is 8GB? |
Previous Message | Michael Paquier | 2014-04-02 04:48:12 | Re: Slow Count-Distinct Query |