Re: zheap: a new storage format for PostgreSQL

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: zheap: a new storage format for PostgreSQL
Date: 2018-03-02 08:05:47
Message-ID: alpine.DEB.2.20.1803020846431.12500@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Amit,

> At EnterpriseDB, we (me and some of my colleagues) are working from more
> than a year on the new storage format in which only the latest version of
> the data is kept in main storage and the old versions are moved to an undo
> log. [...]

This looks more than great!

> *We’ve shown the performance improvement of zheap over heap in a few
> different pgbench scenarios. [...]

> 2. Transaction aborts will be expensive.

ISTM that some scenarii should also test the performance impact when the
zheap storage is expected to be worse than the heap storage, i.e. with
some rollback which will exercise the undo stuff. There does not seem to
be any in your report, I apologise if I misread it.

I would suggest that you can use pgbench scripts such as:

-- commit.sql
\set aid random(1, 100000 * :scale)
BEGIN;
UPDATE pgbench_accounts
SET abalance = abalance + 1
WHERE aid = :aid;
COMMIT;

and

-- rollback.sql
\set aid random(1, 100000 * :scale)
BEGIN;
UPDATE pgbench_accounts
SET abalance = abalance + 1
WHERE aid = :aid;
ROLLBACK;

that can run with various weights to change how much rollback is injected,
eg 1% rollback rate is achieved with:

pgbench -T 10 -P 1 -M prepared -r \
-f SQL/commit(dot)sql(at)99 -f SQL/rollback(dot)sql(at)1

Also, I would be wary of doing only max speed test, and consider more
realistic --rate tests where the tps is fixed.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-03-02 08:06:20 Re: 2018-03 Commitfest Summary (Andres #4)
Previous Message Andrew Dunstan 2018-03-02 08:03:55 Re: Rewriting the test of pg_upgrade as a TAP test - take two