Re: Slow Count-Distinct Query

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
>

In response to

Browse pgsql-performance by date

  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