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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Floris Van Nee <florisvannee(at)optiver(dot)com>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()
Date: 2020-01-27 16:12:26
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


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.


Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2020-01-27 16:45:52 Re: pg_croak, or something like it?
Previous Message Tom Lane 2020-01-27 16:07:53 Re: pg_croak, or something like it?