Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions
От | Tomas Vondra |
---|---|
Тема | Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions |
Дата | |
Msg-id | 20190926214606.q6ad65r4umimc5w3@development обсуждение исходный текст |
Ответ на | Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | pgsql-hackers |
On Thu, Sep 26, 2019 at 04:33:59PM -0300, Alvaro Herrera wrote: >On 2019-Sep-26, Tomas Vondra wrote: > >> Hi, >> >> Attached is an updated patch series, rebased on current master. It does >> fix one memory accounting bug in ReorderBufferToastReplace (the code was >> not properly updating the amount of memory). > >Cool. > >Can we aim to get 0001 pushed during this commitfest, or is that a lost >cause? > It's tempting. The patch has been in the queue for quite a bit of time, and I think it's solid (at least 0001). I'll address the comments from Peter's review about separating the GUC etc. and polish it a bit more. If I manage to do that by Monday, I'll consider pushing it. If anyone feels I shouldn't do that, let me know. The one open question pointed out by Amit is how the patch picks the trasction for eviction. My feeling is that's fine and if needed can be improved later if necessary, but I'll try to construct a worst case (max_connections xacts, each with 64 subxact) to verify. >The large new comment in reorderbuffer.c says that a transaction might >get spilled *or streamed*, but surely that second thing is not correct, >since before the subsequent patches it's not possible to stream >transactions that have not yet finished? > True. That's a residue of reordering the patch series repeatedly, I think. I'll fix that while polishing the patch. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: