Re: Add table access method as an option to pgbench

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: David Zhang <david(dot)zhang(at)highgo(dot)ca>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add table access method as an option to pgbench
Date: 2020-12-27 13:14:53
Message-ID: alpine.DEB.2.22.394.2012260613190.2006135@pseudo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hello Justin,

> src/test/regress/sql/create_am.sql:CREATE ACCESS METHOD heap2 TYPE TABLE HANDLER heap_tableam_handler;
> ...
> src/test/regress/sql/create_am.sql:DROP ACCESS METHOD heap2;

> Or maybe using SET default_tablespace instead of modifying the CREATE sql.
> That'd need to be done separately for indexes, and RESET after creating the
> tables, to avoid accidentally affecting indexes, too.

Why should it not affect indexes?

> @Fabien: I think the table should be created and populated within the same
> transaction, to allow this optimization in v13 to apply during the
> "initialization" phase.
> c6b92041d Skip WAL for new relfilenodes, under wal_level=minimal.


This would be a change of behavior: currently only filling tables is under
an explicit transaction.

That would be a matter for another patch, probably with an added option.

As VACUUM is not transaction compatible, it might be a little bit tricky
to add such a feature. Also I'm not sure about some constraint

ISTM that I submitted a patch a long time ago to allow "()" to control
transaction from the command line, but somehow it got lost or rejected.
I redeveloped it, see attached. I cannot see reliable performance
improvement by playing with (), though.


Attachment Content-Type Size
pgbench-init-tx-1.patch text/x-diff 5.2 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Laurenz Albe 2020-12-27 15:16:03 Re: Add session statistics to pg_stat_database
Previous Message Alexander Korotkov 2020-12-27 09:50:07 Re: range_agg