Re: Add table access method as an option to pgbench - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: Add table access method as an option to pgbench
Date
Msg-id alpine.DEB.2.22.394.2012260613190.2006135@pseudo
Whole thread Raw
In response to Add table access method as an option to pgbench  (David Zhang <david.zhang@highgo.ca>)
Responses Re: Add table access method as an option to pgbench
List 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.

Possibly.

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 
declarations.

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.

-- 
Fabien.
Attachment

pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: range_agg
Next
From: Laurenz Albe
Date:
Subject: Re: Add session statistics to pg_stat_database