3 ms·
My first instinct is that the effect is too large to be real. But that should be something other people could reproduce and verify. The second thought is that i
by fabian2k 2y ago
My first instinct is that the effect is too large to be real. But that should be something other people could reproduce and verify. The second thought is that it might overfit the benchmark code here, but they address it in the post. But any kind of double-digit improvement to Postgres performance would be very interesting.
- pgaddict 2y ago(author here) I agree the +40% effect feels a bit too good, but it only applies to the simple OLTP queries on in-memory data, so the inefficiencies may have unexpectedly large impact. I agree 30-40% would be a massive speedup, and I expected it to disappear with a more diverse profile, but it did not ... The TPC-H speedups (~5-10%) seem much more plausible, considering the binary layout effects we sometimes observe during benchmarking. Anyway, I'd welcome other people trying to reproduce these tests.
- fabian2k 2y agoI looked and there is no mention of BOLT yet in the pgsql-hackers mailing list, that might be the more appropriate place to get more attention on this. Though there are certainly a few PostgreSQL developers reading here as well.
- pgaddict 2y agoTrue. At the moment I don't have anything very "actionable" beyond "it's magically faster", so I wanted to investigate this a bit more before posting to -hackers. For example, after reading the paper I realized BOLT has "-report-bad-layout" option to report cases of bad layout, so I wonder if we could identify places where to reorganize the code. OTOH my blog is syndicated to https://planet.postgresql.org https://planet.postgresql.org, so it's not particularly hidden from the other devs.
- deleted 2y ago[deleted]