Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.
От | Jim Nasby |
---|---|
Тема | Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning. |
Дата | |
Msg-id | c1390a27-065c-54fc-a1d9-bd446b1aecda@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning. (Christophe Pettus <xof@thebuild.com>) |
Список | pgsql-hackers |
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)
В списке pgsql-hackers по дате отправления: