On 2014-08-29 13:29:19 -0400, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.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.
Right. Just adding it unconditionally doesn't sound feasible to me. Our per-row overhead is already too large. And it doesn't sound fun to have the first-class partitions use a different heap tuple format than plain relations. What we could do is to add some sort of 'jump' tuple when moving a tuple from one relation to another. So, when updating a tuple between partitions we add another in the old partition with xmin_jump = xmax_jump = xmax_old and have the jump tuple's content point to the new relation. Far from pretty, but it'd only matter overhead wise when used. > > 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. I admit that you might very well be right there :( Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
