On 08/29/2014 07:15 PM, Tom Lane wrote: > Alvaro Herrera <alvhe...@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Ü -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
