Re: delta relations in AFTER triggers

On Sat, Jan 21, 2017 at 6:37 AM, Kevin Grittner <kgrittn(at)gmail(dot)com> wrote:
> On Fri, Jan 20, 2017 at 2:08 PM, Nico Williams <nico(at)cryptonector(dot)com> wrote:
>> On Fri, Jan 20, 2017 at 01:37:33PM -0600, Kevin Grittner wrote:
>
>>> There is currently plenty of room for pseudo-MV implementations,
>>> and may be for a while. It's a good indication of the need for the
>>> feature in core. An implementation in the guts of core can have
>>> advantages that nothing else can, of course. For example, for
>>> eager application of the deltas, nothing will be able to beat
>>> capturing tuples already in RAM and being looked at for possible
>>> trigger firing into a RAM-with-spill-to-disk tuplestore.
>>
>> BTW, automatic updates of certain types of MVs should be easy: add
>> constraints based on NEW/OLD rows from synthetic triggers to the
>> underlying query.
>
> Convincing me that this is a good idea for actual MVs, versus
> pseudo-MVs using tables, would be an uphill battle. I recognize
> the need to distinguish between MVs which contain recursive CTEs in
> their definitions and MVs that don't, so that the DRed algorithm
> can be used for the former and the counting algorithm for the
> latter; but firing triggers for row-at-a-time maintenance is not
> going to be efficient for very many cases, and the cost of
> identifying those cases to handle them differently is probably
> going to exceed any gains. Comparative benchmarks, once there is
> an implementation using set-based techniques, could potentially
> convince me; but there's not much point arguing about it before
> that exists. :-)

I have moved this patch to the next CF. It would be nice to progress
in this topic in PG10.
--
Michael