| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | Roman Khapov <rkhapov(at)yandex-team(dot)ru> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, michael(at)paquier(dot)xyz, reshkekirill(at)gmail(dot)com |
| Subject: | Re: pgbench --unlogged-tables silently ignored for branches/tellers/history when --partitions is used |
| Date: | 2026-11-11 14:02:26 |
| Message-ID: | CAHGQGwEcOscPBME-p777mKUn2KegTM5=qYY+1ZiMNXFaiP0CoA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Nov 2, 2026 at 6:12 PM Roman Khapov <rkhapov(at)yandex-team(dot)ru> wrote:
> Yes, it is... There is no point in keeping the patch simpler at the
> cost of the option's meaning, so I did V2 that does:
> - keep the PERMANENT exception for pgbench_accounts only: it cannot
> be unlogged when partitioned
> - accounts -> branches FKs are now created on the partitions
> (pgbench_accounts_%) if the unlogged option is on and there are
> partitions
Thanks for updating the patch!
+ if (unlogged_tables && partition_method != PART_NONE)
+ {
+ initPQExpBuffer(&query);
+
+ for (int p = 1; p <= partitions; p++)
This code seems to create foreign keys based on the options specified
in the current pgbench run. IOW, it assumes that --unlogged-tables and
--partitions are specified when creating the foreign keys. But,
that's not necessarily the case. For example, users can create unlogged
partitions and foreign keys separately using -I:
pgbench -i -I dtp --unlogged-tables --partitions=2
pgbench -i -I f
The patch doesn't seem to handle this case. Shouldn't pgbench create
foreign keys based on the actual table persistence and partition list
rather than the current command-line options?
BTW, one concern about the current approach is that creating separate
foreign keys adds one UPDATE trigger on branches for each accounts
partition. The executions of these triggers might affect the benchmark
performance as the partition count grows...
I'm not sure how significant this overhead would be, but I think
it might be better to at least document it. Thought?
Regards,
--
Fujii Masao
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrei Lepikhov | 2026-11-11 14:04:52 | Re: [PATCH 0/2] Fix two hash join costing errors in final_cost_hashjoin() |
| Previous Message | Srinath Reddy Sadipiralla | 2026-11-11 13:51:42 | Re: Standby stuck after walreceiver restart just before a WAL segment boundary |