Re: Improving btree performance through specializing by key shape, take 2

> 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.