Re: On partitioning

Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Tom Lane wrote:
> >> One other interesting thought that occurs to me: are we going to support
> >> UPDATEs that cause a row to belong to a different partition?  If so, how
> >> are we going to handle the update chain links?
> 
> > Bah, I didn't mention it?  My current thinking is that it would be
> > disallowed; if you have chosen your partitioning key well enough it
> > shouldn't be necessary.  As a workaround you can always DELETE/INSERT.
> > Maybe we can allow it later, but for a first cut this seems more than
> > good enough.
> 
> 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.

I hesitate to suggest this, but we have free flag bits in
MultiXactStatus.  We could use a specially marked multixact member to
indicate the OID of the target relation; perhaps set an infomask bit to
indicate that this has happened.  Of course, no HOT updates are possible
so I think it's okay from a heap_prune_chain perspective.  This abuses
the knowledge that OIDs and XIDs are both 32 bits long.  

Since nowhere else we have the space necessary to store the longer data
that a cross-partition update would require, I don't see anything else
ATM.  (For a moment I thought about abusing combo CIDs, but that doesn't
work because this requires to be persistent and visible from other
backends, neither of which is a quality of combocids.)

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