From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Fdw batch insert error out when set batch_size > 65535 |
Date: | 2021-06-09 06:28:29 |
Message-ID: | 1272762.1623220109@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> writes:
>>> I've added a simple regression test to postgres_fdw, testing that batch
>>> sizes > 65535 work fine, and pushed the fix.
>> I was earlier thinking of adding one, but stopped because it might
>> increase the regression test execution time. It looks like that's true
>> - with and without the test case it takes 17 sec and 4 sec
>> respectively on my dev system which is 4X slower. I'm not sure if this
>> is okay.
> The cost, versus the odds of ever detecting a problem, doesn't
> seem like a good tradeoff.
I took a quick look and noted that on buildfarm member longfin
(to take a random example that's sitting a few feet from me),
the time for contrib-install-check went from 34 seconds before
this patch to 40 seconds after. I find that completely
unacceptable compared to the likely value of this test case.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | osumi.takamichi@fujitsu.com | 2021-06-09 06:33:14 | RE: locking [user] catalog tables vs 2pc vs logical rep |
Previous Message | houzj.fnst@fujitsu.com | 2021-06-09 06:20:43 | RE: [bug?] Missed parallel safety checks, and wrong parallel safety |