New polling-strategy for Postgres, select-for-update based

[kagkarlsson]

New SchedulerBuilder methods:

• pollUsingFetchAndLockOnExecute(double lowerLimitFractionOfThreads, double executionsPerBatchFractionOfThreads). The old default, but more customizable.
• pollUsingLockAndFetch(double lowerLimitFractionOfThreads, double upperLimitFractionOfThreads) a new method of polling based on SELECT FOR UPDATE .. SKIP LOCKED RETURNING .... Currently implemented for Postgres

Benchmarks results comparing the default mechanism fetch to the new lock-and-fetch:

	Throughput fetch	TPS fetch (from console)	Throughput lock-and-fetch	TPS lock-and-fetch (from console)
Postgres 4core 25gb ram, 4xVMs(2-core)
20 threads, lower 4.0, upper 20.0	2000	9000	10600	11500
100 threads, lower 2.0, upper 6.0	2560	11000	11200	11200
Postgres 8core 50gb ram, 4xVMs(4-core)
50 threads, lower: 0.5, upper: 4.0	4000	22000	11840	10300

Relevant reading material

• https://www.2ndquadrant.com/en/blog/what-is-select-skip-locked-for-in-postgresql-9-5/
• https://gist.github.com/chanks/7585810

[FreCap]

While working on this code, I faced some challenges in testing/following the code and updating due to the mutual dependency of Scheduler on the Execution and vice versa.

Could we have a more tree-like structure in a way that ExecutePicked gets "trigger"/"handler" interface instead of the scheduler itself?

[kagkarlsson]

Yeah, this a bit of technical debt I have not fixed yet. I do not like passing the full Scheduler here. It should be changed to not reference Scheduler.. haven't taken the time to figure out a good solution yet..