Horton

Re: pgsql: Add parallel-aware hash joins.

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Andres Freund <andres@anarazel.de>, pgsql-committers <pgsql-committers@postgresql.org>
Date: 2018-01-22T23:53:10Z
Lists: pgsql-hackers

Attachments

I wrote:
> Anyway, it looks like we should write off these longfin timings as
> ambient noise :-(

Here's a possibly more useful graph of regression test timings over
the last year.  I pulled this from the buildfarm database: it is the
reported runtime for the "installcheck-C" step in each successful
build of HEAD on dromedary, going back to Jan. 2017.  I picked dromedary
because I know that that machine hasn't gotten any software updates
nor is there anything else very interesting going on on it.  I dropped
three or four obvious outlier reports (possibly those ran during the
machine's nightly backup cron job).  The reported runtime is only
precise to 1s, and a couple seconds jitter is hardly surprising, so
there's a good deal of noise.  Still, it's possible to discern when
I put some effort into test runtime reduction back in April, and
it can be seen that things have gotten notably slower since the
beginning of November.

			regards, tom lane

Commits

  1. Update obsolete sentence in README.parallel.

  2. Rewrite ConditionVariableBroadcast() to avoid live-lock.

  3. Tweak parallel hash join test case in hopes of improving stability.

  4. Rename pg_rewind's copy_file_range() to avoid conflict with new linux syscall.

  5. Fix some minor errors in new PHJ code.

  6. Fix EXPLAIN ANALYZE output for Parallel Hash.

  7. Fix rare assertion failure in parallel hash join.

  8. Cancel CV sleep during subtransaction abort.

  9. Add parallel-aware hash joins.

  10. Fix EXPLAIN ANALYZE of hash join when the leader doesn't participate.

  11. Add some regression tests that exercise hash join code.