Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

From: Tender Wang <tndrwang(at)gmail(dot)com>
To: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Dmitry Koval <d(dot)koval(at)postgrespro(dot)ru>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands
Date: 2024-04-08 10:43:51
Message-ID: CAHewXNkGMPU50QG7V6Q60JGFORfo8LfYO1_GCkCa0VWbmB-fEw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,
I went through the MERGE/SPLIT partition codes today, thanks for the
works. I found some grammar errors:
i. in error messages(Users can see this grammar errors, not friendly).
ii. in codes comments

Alexander Korotkov <aekorotkov(at)gmail(dot)com> 于2024年4月7日周日 06:23写道:

> Hi, Dmitry!
>
> On Fri, Apr 5, 2024 at 4:00 PM Dmitry Koval <d(dot)koval(at)postgrespro(dot)ru>
> wrote:
> > > I've revised the patchset.
> >
> > Thanks for the corrections (especially ddl.sgml).
> > Could you also look at a small optimization for the MERGE PARTITIONS
> > command (in a separate file
> > v31-0003-Additional-patch-for-ALTER-TABLE-.-MERGE-PARTITI.patch, I wrote
> > about it in an email 2024-03-31 00:56:50)?
> >
> > Files v31-0001-*.patch, v31-0002-*.patch are the same as
> > v30-0001-*.patch, v30-0002-*.patch (after rebasing because patch stopped
> > applying due to changes in upstream).
>
> I've pushed 0001 and 0002. I didn't push 0003 for the following reasons.
> 1) This doesn't keep functionality equivalent to 0001. With 0003, the
> merged partition will inherit indexes, constraints, and so on from the
> one of merging partitions.
> 2) This is not necessarily an optimization. Without 0003 indexes on
> the merged partition are created after moving the rows in
> attachPartitionTable(). With 0003 we merge data into the existing
> partition which saves its indexes. That might cause a significant
> performance loss because mass inserts into indexes may be much slower
> than building indexes from scratch.
> I think both aspects need to be carefully considered. Even if we
> accept them, this needs to be documented. I think now it's too late
> for both of these. So, this should wait for v18.
>
> ------
> Regards,
> Alexander Korotkov
>
>
>

--
Tender Wang
OpenPie: https://en.openpie.com/

Attachment Content-Type Size
0001-Fix-some-grammer-errors-from-error-messages-and-code.patch application/octet-stream 6.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tender Wang 2024-04-08 10:54:41 Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()
Previous Message Jelte Fennema-Nio 2024-04-08 10:42:23 Re: Flushing large data immediately in pqcomm