Re: should INSERT SELECT use a BulkInsertState?

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: should INSERT SELECT use a BulkInsertState?
Дата
Msg-id 20200604173047.dirdp6zln7ogj54k@alap3.anarazel.de
обсуждение исходный текст
Ответ на should INSERT SELECT use a BulkInsertState?  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Expand the use of check_canonical_path() for more GUCs
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Atomic operations within spinlocks