MIME-Version: 1.0
References: <c73a1746-0cd0-6bdd-6b23-3ae0b7c0c582@postgrespro.ru>
 <171085360143.2046436.7217841141682511557.pgcf@coridan.postgresql.org>
 <171085858750.2046434.12246066729700037354.pgcf@coridan.postgresql.org>
 <909e16b4-9eda-435c-b033-8294ae4adc05@postgrespro.ru> <CAPpHfdsVQwnZPxaQPwcu1g_01F0d-o=ECRcf14X3CmavJB6vSQ@mail.gmail.com>
 <a83d5a56-ff33-47e8-b2d8-7e9a5d59ee1e@postgrespro.ru> <CAPpHfdsCCV8DOv0Ovu4dTSnuWXiEz_AjuW-J6TPj++tcfEGvRw@mail.gmail.com>
 <3a4b9c1c-3edf-4e29-9629-b4113aefb0f3@postgrespro.ru> <CAPpHfduNYkMVuUSxZjD6u4tZG6aKdhgQcmhr-K9OQfeg56MNww@mail.gmail.com>
 <c3730d78-6081-4c41-9715-d1d192734576@postgrespro.ru>
In-Reply-To: <c3730d78-6081-4c41-9715-d1d192734576@postgrespro.ru>
From: Alexander Korotkov <aekorotkov@gmail.com>
Date: Sun, 7 Apr 2024 01:22:51 +0300
Message-ID: <CAPpHfdtj7YsPaASoVPN+N3H4_Ct+kQw8QY1d_9u7FPnbghkicw@mail.gmail.com>
Subject: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands
To: Dmitry Koval <d.koval@postgrespro.ru>
Cc: pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAPpHfdtj7YsPaASoVPN%2BN3H4_Ct%2BkQw8QY1d_9u7FPnbghkicw%40mail.gmail.com>
Precedence: bulk

Hi, Dmitry!

On Fri, Apr 5, 2024 at 4:00=E2=80=AFPM Dmitry Koval <d.koval@postgrespro.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