Re: [HACKERS] Increase Vacuum ring buffer.

Поиск
Список
Период
Сортировка
От Claudio Freire
Тема Re: [HACKERS] Increase Vacuum ring buffer.
Дата
Msg-id CAGTBQpbVFhzTSCh+-9vtewoRa=6gDS9B6wpSEGyPESk0aafxsA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Increase Vacuum ring buffer.  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On Thu, Jul 27, 2017 at 2:10 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Claudio Freire wrote:
>> On Thu, Jul 27, 2017 at 1:46 PM, Alvaro Herrera
>> <alvherre@2ndquadrant.com> wrote:
>> > Claudio Freire wrote:
>> >
>> >> > The vacuuming the very large table with no index could also take a
>> >> > long time, and it scans and vacuums blocks one by one. So I imagined
>> >> > that we can vacuum the FSM once vacuumed a certain amount of blocks.
>> >> > And that can avoid bloating table during the long-time vacuum.
>> >>
>> >> Could do that. I'll see about doing something of the sort and
>> >> submitting it as a separate patch.
>> >
>> > Vacuuming of the FSM is in no way strictly tied to vacuuming the heap
>> > (it's not really "vacuuming", it's just about updating the upper layers
>> > to match the data in the leaves).  I think we could use the new autovac
>> > "workitem" infrastructure and tack an item there once in a while for FSM
>> > vacuuming ...
>>
>> Well, it *is* tied in the sense that vacuum is the one massively
>> adding free space.
>
> Yes, but if vacuum dies after releasing lots of space but before
> vacuuming FSM, then it's not tied anymore and you could just as well run
> it anytime.

I see your point.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavan Deolasee
Дата:
Сообщение: Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: [HACKERS] GSoC 2017: Foreign Key Arrays