Re: should INSERT SELECT use a BulkInsertState? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: should INSERT SELECT use a BulkInsertState?
Date
Msg-id 20200604173047.dirdp6zln7ogj54k@alap3.anarazel.de
Whole thread Raw
In response to should INSERT SELECT use a BulkInsertState?  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: should INSERT SELECT use a BulkInsertState?  (Daniel Gustafsson <daniel@yesql.se>)
Re: should INSERT SELECT use a BulkInsertState?  (Justin Pryzby <pryzby@telsasoft.com>)
Re: should INSERT SELECT use a BulkInsertState?  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
Hi,

On 2020-05-08 02:25:45 -0500, Justin Pryzby wrote:
> Seems to me it should, at least conditionally.  At least if there's a function
> scan or a relation or ..

Well, the problem is that this can cause very very significant
regressions. As in 10x slower or more. The ringbuffer can cause constant
XLogFlush() calls (due to the lsn interlock), and the eviction from
shared_buffers (regardless of actual available) will mean future vacuums
etc will be much slower.  I think this is likely to cause pretty
widespread regressions on upgrades.

Now, it sucks that we have this problem in the general facility that's
supposed to be used for this kind of bulk operation. But I don't really
see it realistic as expanding use of bulk insert strategies unless we
have some more fundamental fixes.

Regards,

Andres



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Expand the use of check_canonical_path() for more GUCs
Next
From: Tom Lane
Date:
Subject: Re: Atomic operations within spinlocks