From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Sokolov Yura <funny(dot)falcon(at)postgrespro(dot)ru>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers-owner(at)postgresql(dot)org |
Subject: | Re: Increase Vacuum ring buffer. |
Date: | 2017-07-27 17:04:59 |
Message-ID: | CAGTBQpZFJ4VpWatTezepX4sJqm+MDxuJSmCfNhL32S0pV_Oz1A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 27, 2017 at 1:46 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2017-07-27 17:10:01 | Re: Increase Vacuum ring buffer. |
Previous Message | Alvaro Herrera | 2017-07-27 16:46:37 | Re: Increase Vacuum ring buffer. |