Horton

Why do pg_upgrade's test use the serial schedule?

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: pgsql-hackers@postgresql.org, Bruce Momjian <bruce@momjian.us>, Peter Eisentraut <peter_e@gmx.net>
Date: 2018-11-05T21:00:39Z
Lists: pgsql-hackers 
Hi,

The test I'm most commonly waiting for when doing a parallel make check
is pg_upgrade. And to a significant degree that's because it uses the
serial installcheck rather than installcheck-parallel.

Is there a reason to not use installcheck-parallel?

serial:
19.42user 7.77system 1:53.23elapsed 24%CPU (0avgtext+0avgdata 111420maxresident)k
parallel:
20.76user 7.72system 1:27.05elapsed 32%CPU (0avgtext+0avgdata 112300maxresident)k

So, a saving of ~25s.


ISTM we also should disable fsyncs for the postmaster instances. Wins
another ~5s on my laptop, and I suspect it makes a larger difference on
some of the buildfarm animals.

Greetings,

Andres Freund

Commits

  1. Make TupleTableSlots extensible, finish split of existing slot type.

  2. Inline hot path of slot_getsomeattrs().

  3. Compute information about EEOP_*_FETCHSOME at expression init time.

  4. Don't generate tuple deforming functions for virtual slots.

  5. Introduce notion of different types of slots (without implementing them).

  6. Verify that expected slot types match returned slot types.

  7. Rejigger materializing and fetching a HeapTuple from a slot.

  8. Rationalize expression context reset in ExecModifyTable().

  9. Don't require return slots for nodes without projection.

  10. Move EEOP_*_SYSVAR evaluation out of line.

  11. Use installcheck-parallel in pg_upgrade's testsuite.