| From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
|---|---|
| To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
| Cc: | Dmitry Koval <d(dot)koval(at)postgrespro(dot)ru>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Add SPLIT PARTITION/MERGE PARTITIONS commands |
| Date: | 2024-04-28 14:54:16 |
| Message-ID: | Zi5jGIXBptRcH0UV@pryzbyj2023 |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Apr 28, 2024 at 08:18:42AM -0500, Justin Pryzby wrote:
> > I will explore this. Do we copy extended stats when we do CREATE
> > TABLE ... PARTITION OF? I think we need to do the same here.
>
> Right, they're not copied because an extended stats objs on the parent
> does something different than putting stats objects on each child.
> I've convinced myself that it's wrong to copy the parent's stats obj.
> If someone wants stats objects on each child, they'll have to handle
> them specially after MERGE/SPLIT, just as they would for per-child
> defaults/constraints/etc.
I dug up this thread, in which the idea of copying extended stats from
parent to child was considered some 6 years ago, but never implemented;
for consistency, MERGE/SPLIT shouldn't copy extended stats, either.
https://www.postgresql.org/message-id/20180305195750.aecbpihhcvuskzba%40alvherre.pgsql
--
Justin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-04-28 17:45:16 | Re: Fix overflow hazard in timestamp_pl_interval |
| Previous Message | David G. Johnston | 2024-04-28 14:09:09 | Re: Add SPLIT PARTITION/MERGE PARTITIONS commands |