> On Mon, Mar 04, 2024 at 09:39:37PM GMT, Matthias van de Meent wrote: > Performance > ======== > > I haven't retested the results separately yet, but I assume the > performance results of [2] hold mostly true in comparing 0002 vs 0007. > I will do a performance (re-)evaluation of only this patch if so > requested (or once I have time), but please do review the code, too.
Yeah, if you don't mind it would be great to see a performance evaluation for the latest patch. The CF item is stored under the performance after all. In fact, looking at the results in [2], I would even ask for improving them: * The results posted so far seems to have two loads, insert and reindex, both are close to the best-case scenario for this feature. But you've also mentioned in the thread, that worst-case expectation is a hot loop over a B-Tree index without any specifically optimized path. It would be interesting too see how much impact this feature have under such less favorable load. * Just to be on the safe side, could you describe the testing environment? I'm asking, because the variance bars on the graph look suspicious -- they don't seem to directly depend on the number of columns in the index, so probably the variance is introduced by the environment itself. And if I read the graph correctly, in certain cases it's quite a lot of variance (up to -50% on the reindex?). * Do I interpret the results correctly, the 0007 patch got much larger performance boost between 10 and 12 columns? Any explanation why those numbers feature such dramatic difference? * [nit] It would be great to have a bit better color coding for readability. As a side note, I've got a bit lost in the relationship between this patch series and the one with dynamic prefix truncation. Should they be considered fully independent, for convenience of review, or is there anything that has to be taken into account? > [^0] ./configure --enable-depend --enable-tap-tests --enable-cassert > --with-lz4 --enable-debug --with-zstd COPT='-O3 -g3' > --prefix=~/projects/postgresql/pg_install Any particular reason you build with O3? AFAICT most of the time distributions use O2, so it probably will be a bit more realistic.
