Re: Large Commitfest items - Mailing list pgsql-hackers

On Sun, Jul 1, 2018 at 9:36 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
> On 2 July 2018 at 02:50, Andres Freund <andres@anarazel.de> wrote:
>>
>> Hi,
>>
>> On 2018-07-01 14:46:47 -0400, Andrew Dunstan wrote:
>> > There has been some discussion around excluding large items from the
>> > current commitfest, for several reasons. However I don't recall ever
>> > seeing a definition of a large item. It seems to be a bit like "I know
>> > it when I see it."   I've been looking at the current commitfest
>> > entries. Based on that I suggest a heuristic that says a commitfest
>> > item with patches greater than 5000 lines is large.
>>
>> FWIW, I personally think the criteria should rather be "old" or "very
>> small". I.e. for patches that have waited for review being large
>> shouldn't necessarily be an impediment for getting worked on (depending
>> on invasiveness maybe not committed), and very small for newer things
>> should be way below 5kloc.
>>
>
> I agree. I think the idea is to stop people (um, totally not guilty of this)
> from dropping big or intrusive patches in late CFs.
>
> A 10 line patch can be massively intrusive and contentious. A 5000 line
> patch can be a mechanical change that nobody disagrees with, or a mature
> patch that just needed a few tweaks and missed commit in the last CF.
>
> If a line limit is used, we'll get people optimising for the line limit. I
> don't think that's a win.
>
> This benefits from being fuzzy IMO.
>

I totally agree. I never intended to apply this in anything but a
fuzzy way. I just used a heuristic as a way of breaking up the work a
bit.

Note that the intention is to treat this CF a little differently, as
it's taking place while we're still wrapping up Release 11.

If by "very small" we mean small impact, then the 22,000 line update
to the snowball stemmers is argubly small :-)

The following large items (by my rough heuristic) are marked Ready For
Committer and have been around from 3 to 5 Cfs:

Item 1160 Improve Geometric Types
Item 1294 Custom Compression Methods
Item 1421 Flexible Configuration for FTS

I propose we keep them.

As I mentioned, the update to the Snowball stemmers is fairly low
impact, and we can reasonably keep it.

Discussion seems to be ongoing re Pluggable storage API, and in any
case it could have a huge impact, so I suggest we push it out to
Spetember, even though it's been around for 5 CFs.

The following possibly qualify as "old", and could be kept on that
basis, depending on how large we think their impact might be:

Item 1062 Generic Type Subscripting
Item 1238 Multivariate MVC lists and histograms
Item 1247 push aggregation down to base relations and joins
Item 1348 BRIN Bloom and multi-minmax indexes

I'd like to hear some discussion on these.

That leaves the following "large" items which aren't particularly old:

Item 1471 jsonpath
Item 1472 SQL/JSON functions
Item 1473 JSONTABLE
Item 1553 Advanced partition matching for partition-wise join
Item 1574 Transactions involving multiple postgres foreign servers
Item 1648 Precalculate Stable Functions
Item 1649 Undo Log
Item 1685 Push down aggregates below joins

I suggest we keep jsonpath so we can make some progress on SQL/JSON,
and move the remainder to the September CF.

Before long I will post a similar examination of the next set of
smaller items (2000 to 5000 lines).

cheers

andrew

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