From: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
---|---|
To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Iterating on IndexTuple attributes and nbtree page-level dynamic prefix truncation |
Date: | 2021-06-24 16:21:45 |
Message-ID: | CAEze2WhyBT2bKZRdj_U0KS2Sbewa1XoO_BzgpzLC09sa5LUROg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 17 Jun 2021 at 17:14, Matthias van de Meent
<boekewurm+postgres(at)gmail(dot)com> wrote:
>
> I'll try to
> benchmark the patches in this patchset (both 0001, and 0001+0002) in
> the upcoming weekend.
Somewhat delayed, benchmark results are attached. These are based on 7
iterations of the attached benchmark script ('scratch.sql'), with the
latest 'UK Price Paid' dataset. Again, the index_test table is an
unlogged copy of the land_registry_price_paid_uk table, with one
additional trailing always_null column.
Results for 0001 are quite good in the target area of multi-column
indexes in which attcacheoff cannot be used (2-4% for insertion
workloads, 4-12% for reindex workloads), but regresses slightly for
the single unique column insertion test, and are quite a bit worse for
both insert and reindex cases for the attcacheoff-enabled multi-column
index (4% and 18% respectively (!)).
With 0001+0002, further improvements are made in the target area (now
4-7% for the various insertion workloads, 5-14% for reindex). The
regression in the insert- and reindex-workload in attcacheoff-enabled
multi-column indexes is still substantial, but slightly less bad (down
to a 2% and 15% degradation respectively).
Evidently, this needs improvements in the (likely common)
attcacheoff-enabled multi-column case; as I don't think we can
reasonably commit a 10+% regression. I'll work on that this weekend.
Kind regards,
Matthias van de Meent
Benchmarks were all performed on WSL2 running Debian 10, on an AMD
5950X, with shared_buffers = 15GB (which should fit the dataset three
times), enable_indexscan = off, autovacuum disabled, and parallel
workers disabled on the tables, so that the results should be about as
stable as it gets.
Attachment | Content-Type | Size |
---|---|---|
pgbench.master.out.txt | text/plain | 2.1 KB |
pgbench_log.master.26482 | application/octet-stream | 203 bytes |
pgbench.0001.out.txt | text/plain | 2.1 KB |
pgbench_log.0001.20660 | application/octet-stream | 203 bytes |
pgbench.0001+0002.out.txt | text/plain | 2.1 KB |
pgbench_log.0001+0002.22858 | application/octet-stream | 202 bytes |
scratch.sql | application/sql | 1.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-06-24 17:54:59 | Re: subscription/t/010_truncate.pl failure on desmoxytes in REL_13_STABLE |
Previous Message | Ranier Vilela | 2021-06-24 16:05:12 | Re: Assertion failure in HEAD and 13 after calling COMMIT in a stored proc |