Re: Native partitioning tablespace inheritance

On Thu, Apr 12, 2018 at 3:55 PM, Keith Fiske
<keith.fiske@crunchydata.com> wrote:
> Your last example is why I proposed taking the TABLESPACE defined on the
> parent and applying it to the children. Then all the children have one
> defined and nothing breaks as long as all tablespaces are properly defined
> as part of the restoration.

I decided to test this out using the following commands:

create tablespace xkcd location '/Users/rhaas/xkcd';
create table foo (a int, b text) partition by hash (a);
create table foo1 partition of foo for values with (modulus 2, remainder 0);
alter table foo set tablespace xkcd;
create table foo2 partition of foo for values with (modulus 2, remainder 1);

Under the proposed definition, foo2 is going to end up in tablespace
xkcd.  Let's simulate that:

alter table foo2 set tablespace xkcd;

As things stand today, if you dump and restore at this point, foo and
foo1 get dumped with default_tablespace = '' and foo2 gets dumped with
default_tablespace = 'xkcd'.  So you're correct that every child will
get restored into the correct tablespace.  But it appears to me that
the parent's tablespace is not preserved, so some pg_dump change would
be needed to fix that.

> I'm also not sure that we should have this mindset of partitioning working
> as inheritance does either. Inheritance was only used before because it was
> the only mechanism available. And while you do still use it under the hood
> for parts of partitioning, I don't see any reason we should be let people
> assume that partitioning works anything like inheritance. In my opinion they
> are two very distinct options. Now we have "real" partitioning, so let's act
> like it. That doesn't mean defining old behavior as a "bug", I agree. It
> just means we're defining and clarifying how partitioning itself is supposed
> to be working.

Well, let me put it this way.  Someone who assumes that partitioning
works like inheritance except where we've explicitly made it work
differently will be correct.  Someone who assumes something else will
be incorrect.  I'm not saying that we shouldn't change things in the
future.  I think there's a lot of opportunity for improvement.
However, I also think that partitioning shouldn't get to ignore the
feature freeze deadline.  There's been a huge amount of progress in
this release: faster pruning, run-time pruning, indexes, foreign keys,
triggers, hash partitioning, default partitioning, update tuple
routing, partition-wise join & aggregate, and other things.   What
didn't get done should, in my opinion, wait for v12.  I know that's
painful, but IMHO you've got to draw the line someplace, and we picked
a date and should stick with it.

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