Re: Fdw batch insert error out when set batch_size > 65535 - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: Fdw batch insert error out when set batch_size > 65535
Date
Msg-id CALj2ACV_myhPSe2vTofktpKtUq4RUF20gRtxh2RoxkBgPra-_w@mail.gmail.com
Whole thread Raw
In response to Re: Fdw batch insert error out when set batch_size > 65535  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Fdw batch insert error out when set batch_size > 65535
List pgsql-hackers
On Sun, Jun 13, 2021 at 6:10 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> On 2021-Jun-12, Tomas Vondra wrote:
>
> > 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.
>
> Hmm, what if the table is made 1600 columns wide -- would inserting 41
> rows be sufficient to trigger the problem case?  If it does, maybe it
> would reduce the runtime for valgrind/cache-clobber animals enough that
> it's no longer a concern.

Yeah, that's a good idea. PSA patch that creates the table of 1600
columns and inserts 41 rows into the foreign table. If the batch_size
adjustment fix isn't there, we will hit the error. On my dev system,
postgres_fdw contrib regression tests execution time: with and without
the attached patch 4.5 sec and 5.7 sec respectively.

On Sun, Jun 13, 2021 at 7:25 PM Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
> Good idea. I gave that a try, creating a table with 1500 columns and
> inserting 50 rows (so 75k parameters). See the attached patch.

Thanks for the patch. I also prepared a patch, just sharing. I'm okay
if it's ignored.

With Regards,
Bharath Rupireddy.

Attachment

pgsql-hackers by date:

Previous
From: "Jonathan S. Katz"
Date:
Subject: Re: unnesting multirange data types
Next
From: Justin Pryzby
Date:
Subject: Re: unnesting multirange data types