Re: [COMMITTERS] pgsql: Implement table partitioning.

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Christophe Pettus <xof(at)thebuild(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Implement table partitioning.
Date: 2016-12-10 23:19:32
Message-ID: c1390a27-065c-54fc-a1d9-bd446b1aecda@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On 12/10/16 1:02 PM, Christophe Pettus wrote:
>
>> On Dec 9, 2016, at 22:52, Keith Fiske <keith(at)omniti(dot)com> wrote:
>> On Fri, Dec 9, 2016 at 10:01 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> One thing that's tricky/annoying about this is that if you have a
>>> DEFAULT partition and then add a partition, you have to scan the
>>> DEFAULT partition for data that should be moved to the new partition.
>>> That makes what would otherwise be a quick operation slow. Still, I'm
>>> sure there's a market for that feature.
>>
>> I would find that perfectly acceptable as long as a caveat about the performance impact was included in the documentation.
>
> +1. I don't think it's conceptually different from adding a column with a default, in that regard; you just have to know the impact.

FWIW, I can think of another option: always check the default partition
for data, even if the data should only exist in a specific partition. If
that proved to be too expensive in the normal case it could be optional.

Is it possible to manually (and incrementally) move data from the
default partition to a table that will become the partition for that
data and then do a fast cut-over once that's done? That would be akin to
adding a field without a DEFAULT, adding the DEFAULT after that, and
then slowly updating all the existing rows...
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2016-12-11 18:10:14 pgsql: Prevent crash when ts_rewrite() replaces a non-top-level subtree
Previous Message Christophe Pettus 2016-12-10 19:02:19 Re: [COMMITTERS] pgsql: Implement table partitioning.

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-12-10 23:42:50 Re: Back-patch use of unnamed POSIX semaphores for Linux?
Previous Message Petr Jelinek 2016-12-10 22:49:40 Re: snapbuild woes