Insert Benchmark results for MyRocks, InnoDB and Postgres.
Postgres is still boring, as it was for sysbench. I did not find serious regressions. With one exception, version 13.1 was faster & more efficient than 11.10. The exception was for loads with secondary index maintenance.
Conversation
Replying to
I myself put the Postgres index dedup secondary index regression at 2%-3% using the insert benchmark, which is slightly less than what you found (even referenced this in commit message). You can disable dedup using 'deduplicate_items' storage param when necessary, of course.
2
3
I like to think that my general approach to indexing enhancements contributed to the overall lack of regressions since 11. I try to structure enhancements as subtracting old harmful behaviors, not adding new helpful behaviors. The distinction is subtle, but seems important.
1
3
Replying to
That approach seems to be working.
I like the idea of triggering vacuum based on inserts because something has to set those vis map bits. Does insert-triggered vacuum do more work than it needs to do?
1
1
Replying to
I agree that something ought to be setting VM bits (laziness is good, but must be bounded carefully). It's inherently impossible to give a simple answer to your question, though - depends on workload. In general I'm a fan of workload-driven approaches due to issues like that.
Replying to
I repeated my tests twice:
* with index dedup disabled, no impact on regression
* with insert-triggered autovac disabled, regression resolved
Updated blog post, happy to be able to explain it, not suggesting people disable either in production.
1
1
3
Replying to
Cool! It deduplicates index tuples, which could just be versions of the same logical row. As such, it is useful in a variety of contexts that you might not have considered. Dedup complements the deletion stuff (in 13, as well as improved deletion in 14). This could explain a lot.
2