Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

On Tue, Jun 16, 2026 at 5:37 AM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
>
> On Tue, Jun 16, 2026 at 12:36 AM Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> wrote:
> > On Tue, 16 Jun 2026 at 00:50, Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> > >
> > > On Mon, Jun 15, 2026 at 2:07 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> > > >
> > > > I hit an error when I tried this patch.
> > > >
> > > > CREATE TABLE a (a text) PARTITION BY RANGE(a);
> > > > CREATE TABLE a1 PARTITION OF a DEFAULT;
> > > > INSERT INTO a SELECT repeat('1', 9999999);
> > > > CREATE TABLE a2 PARTITION OF a FOR VALUES FROM (2)TO(3);
> > > > ALTER TABLE a MERGE PARTITIONS (a1, a2) INTO a1;
> > > > ERROR: row is too big: size 39264, maximum size 8160
> > >
> > > Thank you for your report. It appears that createPartitionTable()
> > > misses NewRelationCreateToastTable() call (for instance, DefineTable()
> > > has this call). The attached patch implements fix and has tests. I'm
> > > going to push it if no objections.
> >
> > It looks like the patch is missing in the last message.
>

src5=# explain (analyze, timing, costs off) SELECT repeat('1', 9999999);
QUERY PLAN
-----------------------------------------------------
Result (actual time=0.002..0.003 rows=1.00 loops=1)
Planning Time: 1454.745 ms
Execution Time: 0.035 ms
(3 rows)

Time: 1458.413 ms (00:01.458)

The timing above is from an Assert-enabled build.
Could we optimize these tests to make them less expensive to run?

--
jian
https://www.enterprisedb.com/