Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Improve JDBC performance by lowering the min poll loop interval and changing PostgreSQL indexing.
Min poll loop interval is the minimum delay between each task execution. When running a single flow that have a lot of tasks, lowering it lower the delay between each tasks. It is currently configured at 100ms, configuring it to 25ms show a nice performance gain and should still be not too low so the database will not be sollicited too much. See performance gains bellow.
On PostgreSQL, the
queues
table unique index disturb the PostgreSQL cost optimizer that chooses this index when doing the poll query resulting in 10ms poll queries on a table with a few thousands of line.Removing the PK and the index that exists on the columns type and offset, and replacing them with a hash index on the
offset
colm-umn do the trick. There is still an index on theoffset
column but it is no longuer used when doing the poll query. This new index is needed for other queries.Using this flow;
That using this template (all 4 templates are the same):
Gives the following results:
Baseline: 22s
Min poll interval from 100ms to 25ms: 15s
Changing PG indexing: 7s
These two optimizations on top of each other gives a 70% execution time reduction (execution time divided by 3 approx).
Even if not tested thoroughly on EachParallel, a quick test switching EachSequential to EachParalle show also a nice improvement.