Re: [HACKERS] pgbench: Skipping the creating primary keys afterinitialization

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: [HACKERS] pgbench: Skipping the creating primary keys afterinitialization
Дата
Msg-id alpine.DEB.2.20.1709041927450.16641@lancre
обсуждение исходный текст
Ответ на Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список 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:
cannottruncate 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.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Adrien Nayrat
Дата:
Сообщение: Re: [HACKERS] ALTER INDEX .. SET STATISTICS ... behaviour
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Variable substitution in psql backtick expansion