| From: | Christophe Pettus <xof(at)thebuild(dot)com> |
|---|---|
| To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [COMMITTERS] pgsql: Implement table partitioning. |
| Date: | 2016-12-10 19:02:19 |
| Message-ID: | F0C67105-ADFE-4A47-B461-DC5230D6BE43@thebuild.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
> 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2016-12-10 23:19:32 | Re: [COMMITTERS] pgsql: Implement table partitioning. |
| Previous Message | Keith Fiske | 2016-12-10 06:52:44 | Re: [COMMITTERS] pgsql: Implement table partitioning. |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Artur Zakirov | 2016-12-10 21:07:25 | Re: [sqlsmith] Crash in tsquery_rewrite/QTNBinary |
| Previous Message | Robert Haas | 2016-12-10 18:38:27 | Re: Effect of caching hash bucket size while costing |