Re: Vacuum: allow usage of more than 1GB of work mem
От | Andrew Dunstan |
---|---|
Тема | Re: Vacuum: allow usage of more than 1GB of work mem |
Дата | |
Msg-id | a0d6f5a7-f70b-5c8e-3ecd-192bf840ea87@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: Vacuum: allow usage of more than 1GB of work mem (Claudio Freire <klaussfreire@gmail.com>) |
Ответы |
Re: Vacuum: allow usage of more than 1GB of work mem
|
Список | pgsql-hackers |
On 07/12/2018 12:38 PM, Claudio Freire wrote: > On Thu, Jul 12, 2018 at 10:44 AM Andrew Dunstan > <andrew.dunstan@2ndquadrant.com> wrote: >> >> >> On 04/06/2018 08:00 PM, Claudio Freire wrote: >>> On Fri, Apr 6, 2018 at 5:25 PM, Claudio Freire <klaussfreire@gmail.com> wrote: >>>> On Fri, Apr 6, 2018 at 10:39 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote: >>>>> On 06/04/18 01:59, Claudio Freire wrote: >>>>>> The iteration interface, however, seems quite specific for the use >>>>>> case of vacuumlazy, so it's not really a good abstraction. >>>>> Can you elaborate? It does return the items one block at a time. Is that >>>>> what you mean by being specific for vacuumlazy? I guess that's a bit >>>>> special, but if you imagine some other users for this abstraction, it's >>>>> probably not that unusual. For example, if we started using it in bitmap >>>>> heap scans, a bitmap heap scan would also want to get the TIDs one block >>>>> number at a time. >>>> But you're also tying the caller to the format of the buffer holding >>>> those TIDs, for instance. Why would you, when you can have an >>>> interface that just iterates TIDs and let the caller store them >>>> if/however they want? >>>> >>>> I do believe a pure iterator interface is a better interface. >>> Between the b-tree or not discussion and the refactoring to separate >>> the code, I don't think we'll get this in the next 24hs. >>> >>> So I guess we'll have ample time to poner on both issues during the >>> next commit fest. >>> >> >> >> There doesn't seem to have been much pondering done since then, at least >> publicly. Can we make some progress on this? It's been around for a long >> time now. > Yeah, life has kept me busy and I haven't had much time to make > progress here, but I was planning on doing the refactoring as we were > discussing soon. Can't give a time frame for that, but "soonish". I fully understand. I think this needs to go back to "Waiting on Author". cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: