Re: 2018-03 Commitfest Summary (Andres #2)

From: Andres Freund <andres(at)anarazel(dot)de>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 2018-03 Commitfest Summary (Andres #2)
Date: 2018-03-01 22:45:15
Message-ID: 20180301224515.j6s6melbp4iz6m6q@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On 2018-03-01 03:03:44 -0800, Andres Freund wrote:
> Going through all non bugfix CF entries. Here's the summary for the
> entries I could stomach tonight:
>
> RFC: ready for committer
> NR: needs review
> WOA: waiting on author.

Second round.

- Sample values for pg_stat_statements

NR. Submitted to CF -1.

Nontrivial, some issues. Needs some action by reviewers to get to
being committable...

- pg_stat_statements with plans (v02)

NR. Submitted a year ago and immediately booted, re-submitted this
January.

Cool but decidedly nontrivial feature. Should get some review, but I
can't see us getting this in.

- "failed to find parent tuple for heap-only tuple" error as an ERRCODE_DATA_CORRUPTION ereport()

NR. Should probably just get applied. Can't quite make myself care
enough to interrupt right now.

- Function to track shmem reinit time

Tracks time since of last crash restart.

NR. Submitted first 2018-02-28.

Submitted very late, OTOH it's pretty simple and seems to serve a
valid monitoring need.

- Vacuum: allow usage of more than 1GB of work mem

RFC. Has been alive since 2016-11.

I think this is definitely due some serious attention.

- Protect syscache from bloating with negative cache entries

WOA. Has been alive in some form for a year, but current patch form is
recent.

The patch affects a central part of the code, has not gotten any
code review until just now. Likely problematic behaviour. No
benchmarks done. I don't see this going in.

- Convert join OR clauses into UNION queries

NR. ~1 year old.

Feature has been requested several times independently since. Patch
has been rebased, but otherwise not meaningfully changed.

I think some committers need to bite the bullet and review this one.

- SERIALIZABLE with parallel query

NR. A good year old, updated several times.

This is complicated stuff. Robert mentioned a month ago
(CA+TgmoYTiSsLOKG+wPdm2EQ8i+h_3reK4ub_RM-4zX0314r-SQ(at)mail(dot)gmail(dot)com)
that he might commit baring some issues. So I think it has a chance.

- Incremental sort

NR. This is a *very* old "patch" (obviously has evolved).

Looks to be in a reasonable shape. This needs at the very least a few
planner & executor skilled committer cycles to do a review so it can
progress.

- Moving relation extension locks out of heavyweight lock manager

NR.

Path currently stalled a bit due to some edge case performance
concerns we aren't yet sure matter. Otherwise I think close to commit.

- Improve compactify_tuples and PageRepairFragmentation

NR.

Current patch doesn't show that large gains afaict. Makes the way
specialized versions of qsort more maintainable though.

- Full merge join on comparison clause

NR. Patch originates from a few months ago, current incarnation a few
days old.

I suspect this might need more high-level review than it has gotten,
so it seems debatable whether it can get into 11.

- Implicit prepare of statements: replace literals with parameters and store cached plans

NR. Patch is large, invasive, has significant potential to cause performance
regressions. Has gotten very little code level review.

I can't see this getting in this release.

- Surjective indexes

NR. Older patch.

Simon says he likes the patch, and thinks it might be committable.

I still basically think what Tom and I wrote in
https://www.postgresql.org/message-id/15995.1495730260@sss.pgh.pa.us
and following is the right thing. IOW, I don't think we want the
feature with the current implementation. But others obviously
disagree.

I think a few more committers (Tom?) taking a look at the current
patch would be good.

- Gather speed-up

RFC. We'd some discussions about other potential implementations about
one of the pending improvements, Robert evaluated and found it
unconvincing. I think Robert just need to find tuits to commit.

- Fix LWLock degradation on NUMA

RFC. I should probably take a look on this and see if I can get it
committed.

- Partition-wise aggregation/grouping

NR. Older patch origins, development ongoing.

Can't quite judge how likely this is to get in, but seems feasible.

- Exclude partition constaint checking in query execution plan for
partitioned table queries

NR. A few months old.

This patch, not obvious from thread title, removes restrictions that
are already implied by constraints.

Code doesn't look bad, but I've some concern about potential for perf
regression. Seems doable, but needs review work.

- faster partition pruning in planner

NR. A few months old. Actively being reviewed.

- Lazy hash table for snapshot's "xid in progress"

NR. A few months old. Has not gotten any love in the last few fests.

Unless somebody spends some serious time reviewing and evaluating I
don't see this going anywhere.

- Better estimate for filter cost

NR. A few months old, but only recently updated based on feedback.

Not a large patch, but basically unreviewed.

- Pipelining/batch mode support for libpq.

NR. Patch of old origins, largely unreviewed in the last CFs.

The latest version of the patch doesn't look bad, but would at least
need 2-3 polishing rounds. I think the feature is pretty important...

- Runtime Partition Pruning

NR. A few months old. Still quite some churn.

Potentially doable, but would require close attention.

- Removing [Merge]Append nodes which contain a single subpath

NR. A few months old.

This introduces a new concept of a "proxy path" which doesn't seem to
have gotten a lot of design review.

Color me a bit sceptical that this is doable for v11.

- Remove LEFT JOINs in more cases

WOA. Since last fest.

Pinged thread about marking it as RWF.

- Removing useless DISTINCT clauses

WOA. Since last fest.

Pinged thread about marking it as RWF.

- verify ALTER TABLE SET NOT NULL by valid constraints

NR. Path a couple months old.

Has gotten some design level review (no spi) and a small amount of
code review. Patch looks fairly non-intrusive, albeit needing a bit
polish. Should be doable.

- ALTER TABLE ADD COLUMN fast default

WOA. Recent form of patch created December. Heavy churn.

Possibly can get ready, but that'll be some work.

- MCV lists for highly skewed distributions

WOA, but Dean seems to feel it's ready to be committed and plans to do
so.

Pinged.

- Range Merge Join

NR. Old patch origins.

This patch hasn't gotten that much code level review in the last
iterations, and has basically been in needs-review for a CF+. It's
not a huge patch, but certainly also not trivial.

- WIP: Precalculate stable functions

WOA. Patch hasn't been updated since last fest, even though there's
pending review.

I'd RWF.

- Parallel Aggregates for string_agg and array_agg

WOA, patch hails from mid December.

Hasn't gotten any sort of review yet. It's not a particularly invasive
patch though.

- Optimize Arm64 crc32c implementation in Postgresql

WOA, patch from January, hadn't gotten any review until just now.

Seems a simple enough idea, but there's no benchmarks or anything
yet. I'd not necessarily aim to merge this fest, but giving some
feedback seems like a good plan.

- Faster inserts with mostly-monotonically increasing values

NR, patch from Dec, CF entry created Feb.

Nice performance improvement. Hasn't gotten that much review, and it
appears Peter Geoghegan has some correctness concerns. Not sure.

- OFFSET optimisation for IndexScan using visibility map

NR, patch from 2018-01-31.

This hasn't gotten code level review yet, and there's some executor
structure implications. It seems unlikely to be wise to target this
for v11. Some feedback would be good though.

- Speed up WAL file removal during recovery

NR. Patch from 2017-11-16, CF entry from 2018-02-20.

Hasn't quite gotten enough attention yet, but the original proposal is
a fairly short patch.

- file cloning in pg_upgrade and CREATE DATABASE

NR. Patch from 2018-02-23.

This patch obviously is fairly late, OTOH it's by a committer and not
hugely complicated...

- hash joins with bloom filters

NR, patch from 2018-02-20.

This is a major new patch, arriving just before the last CF. I think
this should be moved to the next fest.

- Nested ConvertRowtypeExpr optimization

NR, patch arrived 2018-02-27.

This is a medium sized patch, with open questions, submitted two days
before the last CF starts. I think this should be moved.

- JIT compiling expressions & tuple deforming

NR, current CF entry is from 2018-02-28, but there have been previous
ones, work has been ongoing all over the last two years.

I'm not neutral on this one obviously ;). I plan to continue working
towards commit on this one.

- new plpgsql extra_checks

WOA, but recently set to that status. Patch essentially from
2017-01-11.

I'm not really sure there's agreement we want this.

- "Possibility to controll plpgsql plan cache behave"

NR, current incarnation is from late last year. Note that the patch
doesn't at all do anymore what the subject says. It's GUCs that can
force custom / generic plans.

Seems simple, if we want it.

- Jsonb transform for pl/perl & pl/python

Peter claimed this as a committer, so I assume they're going to be
dealt with.

- GET DIAGNOSTICS FUNCTION_NAME

WOA.

Conclusion of thread seems to be that we do not want this. Move to
rejected?

- Add missing type conversion functions for PL/Python

NR. Added only 2018-01-31.

This adds conversions between python's int float types and int{2,4,8},
numeric, float{4,8}.

Pretty simple patch, and it seems reasonable to this. I think there's
a bit too much duplication in the code. One could argue that this
ought to be done via transforms, but I'm not fully convinced.

- various procedure related patches

NR, Peter is working on them.

- Remove special wraparound code for pg_serial SLRU

NR, old origins.

I think this actually closer to RFC than NR. I think we should just
commit this.

- 64-bit transaction identifiers

NR, old-ish.

This certainly hasn't gotten enough review. But I see no chance that
we can get this into v11 at the current state. It's too invasive and
there's barely been any analysis. There's some preliminary patches
(e.g. 64bit int GUCs) that could get in, if somebody wants to look at
that.

I think we should give the patch a bit of review and then move it.

Stopping here for a coffee, will try to get the rest done
afterwards. Also, there are too many patches!

- Andres

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2018-03-01 22:47:58 pgstat_report_activity() and parallel CREATE INDEX (was: Parallel index creation & pg_stat_activity)
Previous Message Andres Freund 2018-03-01 22:42:31 Re: Optimize Arm64 crc32c implementation in Postgresql