On 12/10/16 1:02 PM, Christophe Pettus wrote:
>
>> On Dec 9, 2016, at 22:52, Keith Fiske <keith@omniti.com> wrote:
>> On Fri, Dec 9, 2016 at 10:01 PM, Robert Haas <robertmhaas@gmail.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
knowthe 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)
