Re: Extend pgbench partitioning to pgbench_history

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: Extend pgbench partitioning to pgbench_history
Дата
Msg-id 295702e4-d634-4a60-823c-9c7710bd3269@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Extend pgbench partitioning to pgbench_history  (Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>)
Ответы Re: Extend pgbench partitioning to pgbench_history  (Melanie Plageman <melanieplageman@gmail.com>)
Список 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



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

Предыдущее
От: Antonin Houska
Дата:
Сообщение: Re: why there is not VACUUM FULL CONCURRENTLY?
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Add pg_basetype() function to obtain a DOMAIN base type