Re: Extend pgbench partitioning to pgbench_history

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: Gabriele Bartolini <gabriele(dot)bartolini(at)enterprisedb(dot)com>, Abhijit Menon-Sen <ams(at)toroid(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Extend pgbench partitioning to pgbench_history
Date: 2024-02-16 17:50:19
Message-ID: 295702e4-d634-4a60-823c-9c7710bd3269@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Gabriele,

I think the improvement makes sense (it's indeed a bit strange to not
partition the history table), and the patch looks good.

I did think about whether this should be optional in some way - that is,
separate from partitioning the accounts table, and users would have to
explicitly enable (or disable) it. But I don't think we need to do that.

The vast majority of users simply want to partition everything. And this
is just one way to partition the database anyway, it's our opinion on
how to do that, but there's many other options how we might partition
the tables, and we don't (and don't want too) have options for that.

The only case that I can think of where this might matter is when
running a benchmarks that will be compared to some earlier results
(executed using an older pgbench version). That will be affected by
this, but I don't think we make many promises about compatibility in
this regard ... it's probably better to always compare results only from
the same pgbench version, I guess.

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2024-02-16 18:16:18 Re: Add pg_basetype() function to obtain a DOMAIN base type
Previous Message Antonin Houska 2024-02-16 17:43:29 Re: why there is not VACUUM FULL CONCURRENTLY?