Re: On partitioning

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: On partitioning
Date: 2014-08-29 17:29:19
Message-ID: 22162.1409333359@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2014-08-29 13:15:16 -0400, Tom Lane wrote:
>> Hm. I certainly agree that it's a case that could be disallowed for a
>> first cut, but it'd be nice to have some clue about how we might allow it
>> eventually.

> Not pretty, but we could set t_ctid to some 'magic' value when switching
> partitions. Everything chasing ctid chains could then error out when
> hitting a invisible row with such a t_ctid.

An actual fix would presumably involve adding a partition number to the
ctid chain field in tuples in partitioned tables. The reason I bring it
up now is that we'd have to commit to doing that (or at least leaving room
for it) in the first implementation, if we don't want to have an on-disk
compatibility break.

There is certainly room to argue that the value of this capability isn't
worth the disk space this solution would eat. But we should have that
argument while the option is still feasible ...

> The usecases for doing such
> updates really are more maintenance style commands, so it's possibly not
> too bad from a usability POV :(

I'm afraid that might just be wishful thinking.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-08-29 17:33:35 Re: [v9.5] Custom Plan API
Previous Message Andres Freund 2014-08-29 17:26:37 Inverse of pg_get_serial_sequence?