Re: partitioned indexes and tablespaces

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: partitioned indexes and tablespaces
Дата
Msg-id 20181102231215.26fwfg66vdnlckq2@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: partitioned indexes and tablespaces  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: partitioned indexes and tablespaces  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Re: partitioned indexes and tablespaces  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 2018-Nov-03, Michael Paquier wrote:

> On Fri, Nov 02, 2018 at 03:53:51PM -0300, Alvaro Herrera wrote:
> > In this thread I'm not proposing to change the behavior for tables, only
> > for indexes.  If people want to change behavior for tables (and I agree
> > with doing so), they can start their own threads.
> 
> Changing this behavior on back-branches is not a good idea I think
> because that changes the representation of the pg_class entries in the
> catalogs by adding the reltablespace reference for a partitioned index
> which does not exist now.  We are long past the time of doing such
> changes on v11, but that can perfectly be done for v12.

With all due respect, this argument makes no sense.  All partitioned
indexes that exist today have a null reltablespace (all pg_class rows
already have a reltablespace column; I'm not changing that).  If users
want to keep the current behavior (i.e. that indexes on future
partitions are created in the default tablespace), all they have to do
is not send any ALTER INDEX changing the index's tablespace.

You're saying that people currently running Postgres 11 that are
doing "CREATE INDEX ... TABLESPACE foo" will be surprised because the
index ends up in tablespace foo for partitions they create afterwards.

Additionally, you're saying that all people currently doing
ALTER INDEX ... SET TABLESPACE foo
expect that
1. the parent partitioned index silently does not change at all
2. the indexes on future partitions end up in the default tablespace.

I cannot see how that's for real.

Furthermore, I think delaying this change to pg12 serves nobody, because
it just means that there will be a behavior difference for no reason.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: pg_promote not marked as parallel-restricted in pg_proc.dat
Следующее
От: Andreas 'ads' Scherbaum
Дата:
Сообщение: Re: INSTALL file