Re: pgbench: Skipping the creating primary keys after initialization

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgbench: Skipping the creating primary keys after initialization
Date: 2017-09-04 17:33:11
Message-ID: alpine.DEB.2.20.1709041927450.16641@lancre
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers


Hello Masahiko-san,

>>> Currently TRUNCATE pgbench_accounts command is executed within a
>>> transaction started immediately before it. If we move it out of the
>>> transaction, the table data will be truncated even if the copying data
>>> failed. Maybe we can do TRUNCATE pgbench_accounts, pgbench_history
>>> instead. Thought?
>>
>>
>> Keep the truncate in the transaction, and truncate both (or all?) tables
>> together.
>
> Attached latest patch incorporated the comments I got so far. Please review it.

"g" does not work for me yet when after "f", only the message is slightly
different, it chokes on another dependency, branches instead of accounts.

sh> ./pgbench -i -I ctpfg
cleaning up...
creating tables...
set primary keys...
set foreign keys...
ERROR: cannot truncate a table referenced in a foreign key constraint
DETAIL: Table "pgbench_history" references "pgbench_branches".
HINT: Truncate table "pgbench_history" at the same time, or use TRUNCATE ... CASCADE.

I think that the whole data generation should be in *one* transaction
which starts with "truncate pgbench_history, pgbench_branches,
pgbench_tellers, pgbench_accounts;"

In passing, I think that the documentation should tell explicitely what
the default value is (aka "ctgvp").

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-09-04 17:35:40 Re: Variable substitution in psql backtick expansion
Previous Message Adrien Nayrat 2017-09-04 17:30:11 Re: ALTER INDEX .. SET STATISTICS ... behaviour