Re: [HACKERS] MERGE SQL Statement for PG11

Greetings,

* Peter Geoghegan (pg(at)bowt(dot)ie) wrote:
> On Mon, Feb 5, 2018 at 7:56 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > I don't think you get to make a unilateral decision to exclude
> > features that work everywhere else from the scope of this patch. If
> > there is agreement that those features can be left out of scope, then
> > that is one thing, but so far all the commentary about the things that
> > you've chosen to exclude has been negative. Nor have you really given
> > any reason why they should be exempt. You've pointed out that
> > parallel query doesn't handle everything (which is certainly true, but
> > does not mean that any feature from now and the end of time is allowed
> > to exclude from scope whatever seems inconvenient regardless of
> > contrary community consensus) and you've pointed out here and
> > elsewhere that somebody could go add the features you omitted later
> > (which is also true, but misses the general point that we want
> > committed patches to be reasonably complete already, not have big gaps
> > that someone will have to fix later).
>
> For me, the concern is not really the omission of support for certain
> features as such. The concern is that those omissions hint that there
> is a problem with the design itself, particularly in the optimizer.
> Allowing subselects in the UPDATE part of a MERGE do not seem like
> they could be written as a neat adjunct to what Simon already came up
> with. If that was possible, Simon probably already would have done it.

I tend to agree with Robert here that we should be trying to include
relatively complete features which work with the rest of the system
whenever possible. To the extent that partitioning wasn't entirely
complete, I think the subsequent work on it (partituclarly in this
release cycle) clearly demonstrates that it's a huge project which
needed multiple releases, but that's an exception to the general rule.

That was also what seemed to be the consensus coming out of the FOSDEM
Developer meeting (notes here:
https://wiki.postgresql.org/wiki/FOSDEM/PGDay_2018_Developer_Meeting).
There was also discussion and apparent consensus that performance issues
or sub-par plans are reasonable for an initial feature (as happened with
leakproof views and subsequently RLS until the rework which improved it
greatly in later releases).

Coming out of that, my understanding is that Simon is planning to have a
patch which implements RLS and partitioning (though the query plans for
partitioning may be sub-par and not ideal) as part of MERGE and I've
agreed to review at least the RLS bits (though my intention is to at
least go through the rest of the patch as well, though likely in less
detail). Of course, I encourage others to review it as well.

Thanks!

Stephen