From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
        "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Fdw batch insert error out when set batch_size > 65535
In-reply-to: <ec642523-bf1a-a4cd-013c-b789ff091849@enterprisedb.com>
References: 
 <OS0PR01MB571603973C0AC2874AD6BF2594299@OS0PR01MB5716.jpnprd01.prod.outlook.com>
 <OS0PR01MB57160ADFD5010254C8D1CE6594259@OS0PR01MB5716.jpnprd01.prod.outlook.com>
 <CALj2ACVvrd6LGga6UzOu17GzW0cmaS-F30KMBSxKsA+Zw8Z=BQ@mail.gmail.com>
 <CALj2ACXBJ3a7MLbCAGA=5dneYsD720KPp1Pot-kKVM1YFPkESA@mail.gmail.com>
 <73ed9fba-df31-462f-cd4a-28602254cd9f@enterprisedb.com>
 <CALj2ACXq8a=FdrPDa=_wMrvOwcZjrNfCdeyfG-2dt17LyBEc=g@mail.gmail.com>
 <OS0PR01MB571674E988B480E82066EA7794239@OS0PR01MB5716.jpnprd01.prod.outlook.com>
 <fe6cea83-b378-dce0-0506-03ff9a1a581d@enterprisedb.com>
 <CALj2ACUxf+PRaTVPEY-pV_nNgsB0_U2uU3u8GqMKcF-6M2exjw@mail.gmail.com>
 <68b4d5bd-d9fd-4337-e677-0bc5b3b7db6f@enterprisedb.com>
 <CALj2ACXoxbNhpKx2r29OyBdx+fA51Xsv80B-9-xyp1CeBL3ckQ@mail.gmail.com> <1!
 271666.1623218746@sss.pgh.pa.us> <1272762.1623220109@sss.pgh.pa.us>
 <06650e9a-086c-0020-614f-f7ff39609c43@enterprisedb.com>
 <1291662.1623245310@sss.pgh.pa.us>
 <6abb33e8-db04-3d39-4f9a-7a22a75e0cc8@enterprisedb.com> <e!
 c642523-bf1a-a4cd-013c-b789ff091849@enterprisedb.com>
Comments: In-reply-to Tomas Vondra <tomas.vondra@enterprisedb.com>
	message dated "Sat, 12 Jun 2021 00:39:02 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2131016.1623451468.1@sss.pgh.pa.us>
Date: Fri, 11 Jun 2021 18:44:28 -0400
Message-ID: <2131017.1623451468@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2131017.1623451468%40sss.pgh.pa.us>
Precedence: bulk

Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> There's one caveat, though - for regular builds the slowdown is pretty
> much eliminated. But with valgrind it's still considerably slower. For
> postgres_fdw the "make check" used to take ~5 minutes for me, now it
> takes >1h. And yes, this is entirely due to the new test case which is
> generating / inserting 70k rows. So maybe the test case is not worth it
> after all, and we should get rid of it.

I bet the CLOBBER_CACHE animals won't like it much either.

I suggest what we do is leave it in place for long enough to get
a round of reports from those slow animals, and then (assuming
those reports are positive) drop the test.

			regards, tom lane