On Sat, Jan 21, 2017 at 6:37 AM, Kevin Grittner <kgri...@gmail.com> wrote: > On Fri, Jan 20, 2017 at 2:08 PM, Nico Williams <n...@cryptonector.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
