Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()

Hi,

On 2020-01-27 15:42:06 +0000, Floris Van Nee wrote:
>
> > He reported that the problem went away with the patches applied. The
> > following pgbench SELECT-only result was sent to me privately:
> >
> > before:
> > single: tps = 30300.202363 (excluding connections establishing)
> > all cores: tps = 1026853.447047 (excluding connections establishing)
> >
> > after:
> > single: tps = 31120.452919 (excluding connections establishing)
> > all cores: tps = 1032376.361006 (excluding connections establishing)
> >
> > (Actually, he tested something slightly different -- he inlined
> > _bt_compare() in his own way instead of using my 0002-*, and didn't use the
> > 0003-* optimization at all.)
> >
> > Apparently this was a large multi-socket machine. Those are hard to
> > come by.

I'd not say "large multi socket", 2 x XeonGold 5215, 192GB RAM.

> I could do some tests with the patch on some larger machines. What
> exact tests do you propose? Are there some specific postgresql.conf
> settings and pgbench initialization you recommend for this? And was
> the test above just running 'pgbench -S' select-only with specific -T,
> -j and -c parameters?

The above test was IIRC:

PGOPTIONS='-c vacuum_freeze_min_age=0' pgbench -i -q -s 300
with a restart here, and a
SELECT SUM(pg_prewarm(oid, 'buffer')) FROM pg_class WHERE relkind IN ('r', 'i', 't');
after starting, and then
PGOPTIONS='-c default_transaction_isolation=repeatable\ read' pgbench -n -M prepared -P1 -c100 -j72 -T1000 -S

The freeze, restart & prewarm are to have fairer comparisons between
tests, without needing to recreate the database from scratch.

Greetings,

Andres Freund