Re: partitioned indexes and tablespaces

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: partitioned indexes and tablespaces
Date: 2018-11-03 18:22:00
Message-ID: CA+Tgmoa09FP_gujzPgjgGvbmWrXTqoR296WP+sTNzSwUj+Q3Eg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 2, 2018 at 7:12 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> 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

I hope not, because that column isn't nullable.

> 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.

Well, you've guaranteed that already. Now 11 will be different from
11.1, and tables will be different from indexes until somebody goes
and makes that consistent again.

I now wish I hadn't objected to changing the behavior in April. If
I'd know that the alternative was going to be to change it in
November, back-patched, two days before a minor release, with more
people voting against the change than for it, I would have kept my
mouth shut.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-11-03 18:30:40 Re: plruby: rb_iterate symbol clash with libruby.so
Previous Message Tom Lane 2018-11-03 18:19:46 Re: plruby: rb_iterate symbol clash with libruby.so