Re: should INSERT SELECT use a BulkInsertState?
От | Daniel Gustafsson |
---|---|
Тема | Re: should INSERT SELECT use a BulkInsertState? |
Дата | |
Msg-id | 1C04654B-C4F8-4E2D-A636-6AC5799A86AB@yesql.se обсуждение исходный текст |
Ответ на | Re: should INSERT SELECT use a BulkInsertState? (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
> On 4 Jun 2020, at 19:30, Andres Freund <andres@anarazel.de> 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. Based on the above, and the lack of activity in the thread, it sounds like this patch should be marked Returned with Feedback; but Justin: you set it to Waiting on Author at the start of the commitfest, are you working on a new version? cheers ./daniel
В списке pgsql-hackers по дате отправления: