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  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Shared buffer access rule violations?