Re: should INSERT SELECT use a BulkInsertState?
| От | Justin Pryzby |
|---|---|
| Тема | Re: should INSERT SELECT use a BulkInsertState? |
| Дата | |
| Msg-id | 20201016210511.GC9241@telsasoft.com обсуждение исходный текст |
| Ответ на | Re: should INSERT SELECT use a BulkInsertState? (Justin Pryzby <pryzby@telsasoft.com>) |
| Ответы |
Re: should INSERT SELECT use a BulkInsertState?
|
| Список | pgsql-hackers |
On Sat, Sep 19, 2020 at 08:32:15AM -0500, Justin Pryzby wrote: > On Sun, Jul 12, 2020 at 08:57:00PM -0500, Justin Pryzby wrote: > > On Thu, Jun 04, 2020 at 10:30:47AM -0700, Andres Freund wrote: > > > 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. > > > > I made this conditional on BEGIN BULK/SET bulk, so I'll solicit comments on that. > > @cfbot: rebased again -- Justin
Вложения
В списке pgsql-hackers по дате отправления: