On 08/29/2014 07:15 PM, 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.
There needs to be some structure that is specific to partitions and not
multiple plain tables which would then be used for both update chains and
cross-partition indexes (as you seem to imply by jumping from indexes
to update chains a few posts back).
It would need to replace plain tid (pagenr, tupnr) with triple of (partid,
pagenr, tupnr).
Cross-partition indexes are especially needed if we want to allow putting
UNIQUE constraints on non-partition-key columns.
Cheers
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ
