Re: Feature: triggers on materialized views

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Mitar <mmitar(at)gmail(dot)com>
Cc: David Fetter <david(at)fetter(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Kevin Grittner <kgrittn(at)gmail(dot)com>
Subject: Re: Feature: triggers on materialized views
Date: 2018-12-26 12:38:56
Message-ID: 20181226123855.wy3oszymyztmtajw@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2018-Dec-25, Mitar wrote:

> On Tue, Dec 25, 2018 at 7:05 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> > But then I'm not clear *why* you would like to do a non-concurrent
> > refresh.
>
> I mostly wanted to support if for two reasons:
>
> - completeness: maybe we cannot imagine the use case yet, but somebody
> might in the future

Understood. We don't like features that fail to work in conjunction
with other features, so this is a good goal to keep in mind.

> - getting trigger calls for initial inserts: you can then create
> materialized view without data, attach triggers, and then run a
> regular refresh; this allows you to have only one code path to process
> any (including initial) changes to the view through notifications,
> instead of handling initial data differently

Sounds like you could do this by fixing concurrent refresh to also work
when the MV is WITH NO DATA.

> > Maybe your situation would be best served by forbidding non-
> > concurrent refresh when the MV contains any triggers.
>
> If this would be acceptable by the community, I could do it.

I think your chances are 50%/50% that this would appear acceptable.

> > Alternatively, maybe reimplement non-concurrent refresh so that it works
> > identically to concurrent refresh (except with a stronger lock). Not
> > sure if this implies any performance penalties.
>
> Ah, yes. I could just do TRUNCATE and INSERT, instead of heap swap.
> That would then generate reasonable trigger calls.

Right.

> Are there any existing benchmarks for such operations I could use to
> see if there are any performance changes if I change implementation
> here? Any guidelines how to evaluate this?

Not that I know of. Typically the developer of a feature comes up with
appropriate performance tests also, targetting average and worst cases.

If the performance worsens with the different implementation, one idea
is to keep both and only use the slow one when triggers are present.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2018-12-26 13:37:51 Re: Alternative to \copy in psql modelled after \g
Previous Message Alvaro Herrera 2018-12-26 12:32:56 Re: chained transactions