From: | Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> |
---|---|
To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Dmitry Koval <d(dot)koval(at)postgrespro(dot)ru>, Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Subject: | Re: Add SPLIT PARTITION/MERGE PARTITIONS commands |
Date: | 2024-05-17 11:02:40 |
Message-ID: | CALT9ZEHCDCXvg_=9oPb99mHzJPE=+N-DOodsuE20UorY35Jkzw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi, Alexander:
On Fri, 17 May 2024 at 14:05, Alexander Korotkov <aekorotkov(at)gmail(dot)com>
wrote:
> On Tue, May 14, 2024 at 5:49 PM Justin Pryzby <pryzby(at)telsasoft(dot)com>
> wrote:
> > On Thu, May 09, 2024 at 12:51:32AM +0300, Alexander Korotkov wrote:
> > > > > However, parent's table extended statistics already covers all its
> > > > > children.
> > > >
> > > > => That's the wrong explanation. It's not that "stats on the parent
> > > > table cover its children". It's that there are two types of stats:
> > > > stats for the "table hierarchy" and stats for the individual table.
> > > > That's true for single-column stats as well as for extended stats.
> > > > In both cases, that's indicated by the inh flag in the code and in
> the
> > > > catalog.
> > > >
> > > > The right explanation is that extended stats on partitioned tables
> are
> > > > not similar to indexes. Indexes on parent table are nothing other
> than
> > > > a mechanism to create indexes on the child tables. That's not true
> for
> > > > stats.
> > > >
> > > > See also my prior messages
> > > > ZiJW1g2nbQs9ekwK(at)pryzbyj2023
> > > > Zi5Msg74C61DjJKW(at)pryzbyj2023
> > >
> > > Yes, I understand that parents pg_statistic entry with stainherit ==
> > > true includes statistics for the children. I tried to express this by
> > > word "covers". But you're right, this is the wrong explanation.
> > >
> > > Can I, please, ask you to revise the patch?
> >
> > I tried to make this clear but it'd be nice if someone (Tomas/Alvaro?)
> > would check that this says what's wanted.
>
> Thank you!
>
> I've assembled the patches with the pending fixes.
> 0001 – The patch by Dmitry Koval for fixing detection of name
> collision in SPLIT partition operation. Also, I found that name
> collision detection doesn't work well for MERGE partitions. I've
> added fix for that to this patch as well.
> 0002 -– Patch for skipping copy of extended statistics. I would
> appreciate more feedback about wording, but I'd like to get a correct
> behavior into the source tree sooner. If the docs and/or comments
> need further improvements, we can fix that later.
>
> I'm going to push both if no objections.
>
Thank you for working on this patch set!
Some minor things:
0001:
partition_split.sql
157 +-- Check that detection, that the new partition has the same name as
one of
158 +-- the merged partitions, works correctly for temporary partitions
Test for split with comment for merge. Maybe better something like:
"Split partition of a temporary table when one of the partitions after
split has the same name as the partition being split"
0002:
analgous -> analogous (maybe better using "like" instead of "analogous to")
heirarchy -> hierarchy
alter_table.sgml:
Maybe in documentation it's better not to provide reasoning, just state how
it works:
for consistency with <command>CREATE TABLE PARTITION OF</command> ->
similar to <command>CREATE TABLE PARTITION OF</command>
Regards,
Pavel Borisov
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Borisov | 2024-05-17 11:09:04 | Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index. |
Previous Message | Alexander Korotkov | 2024-05-17 10:11:32 | Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index. |