From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: should INSERT SELECT use a BulkInsertState? |
Date: | 2020-06-04 17:30:47 |
Message-ID: | 20200604173047.dirdp6zln7ogj54k@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-06-04 17:57:19 | Re: Atomic operations within spinlocks |
Previous Message | Tom Lane | 2020-06-04 17:22:53 | Re: Expand the use of check_canonical_path() for more GUCs |