Message-ID: <5400C280.8070305@2ndQuadrant.com>
Date: Fri, 29 Aug 2014 20:12:16 +0200
From: Hannu Krosing <hannu@2ndQuadrant.com>
Organization: 2ndQuadrant Nordic =?windows-1252?Q?O=DC?=
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>,
 Alvaro Herrera <alvherre@2ndquadrant.com>
CC: Greg Stark <stark@mit.edu>, Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: On partitioning
References: <20140829155607.GF7705@eldon.alvh.no-ip.org>
 <CAM-w4HN2ENWCBmi1nXQvBHVF3ZxnxNSz9_q4v1H8zOOTHunr4g@mail.gmail.com>
 <21166.1409331142@sss.pgh.pa.us> <20140829171228.GG7705@eldon.alvh.no-ip.org>
 <21834.1409332516@sss.pgh.pa.us>
In-Reply-To: <21834.1409332516@sss.pgh.pa.us>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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Ü


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers