On Tue, Apr 3, 2018 at 10:19 AM, Claudio Freire wrote:
> On Thu, Mar 29, 2018 at 2:09 PM, Tom Lane wrote:
>> Claudio Freire writes:
>>> On Wed, Mar 28, 2018 at 6:54 PM, Tom Lane wrote:
After 0001,
there's no reason to assume that vacuum is particularly likely to get
cancelled bet
On Thu, Mar 29, 2018 at 2:09 PM, Tom Lane wrote:
> Claudio Freire writes:
>> On Wed, Mar 28, 2018 at 6:54 PM, Tom Lane wrote:
>>> After 0001,
>>> there's no reason to assume that vacuum is particularly likely to get
>>> cancelled between having made cleanups and having updated the upper FSM
>>>
On Thu, Mar 29, 2018 at 7:55 PM, Tom Lane wrote:
> I wrote:
>> I have to go do something
>> else right now, but I'll take a closer look at 0004 later.
>
> OK, so after studying 0004, it seems to me that we could do it more
> simply as attached; that is, move the IndexFreeSpaceMapVacuum calls
> int
I wrote:
> I have to go do something
> else right now, but I'll take a closer look at 0004 later.
OK, so after studying 0004, it seems to me that we could do it more
simply as attached; that is, move the IndexFreeSpaceMapVacuum calls
into btvacuumscan/spgvacuumscan, do them only if we found any re
Claudio Freire writes:
> On Wed, Mar 28, 2018 at 6:54 PM, Tom Lane wrote:
>> After 0001,
>> there's no reason to assume that vacuum is particularly likely to get
>> cancelled between having made cleanups and having updated the upper FSM
>> levels. (Maybe the odds are a bit more for the no-indexe
Claudio Freire writes:
> v10 counted the number of blocks with updated free space to vacuum the
> FSM only after a lot of changes to it were made. This will vacuum the
> FSM after *scanning* a lot of pages, even if little modifications were
> made to them.
Yes, that's exactly the point. We still
On Wed, Mar 28, 2018 at 6:54 PM, Tom Lane wrote:
> Claudio Freire writes:
>> Attached patches, rebased and modified as discussed:
>> 1 no longer does tree pruning, it just vacuums a range of the FSM
>> 2 reintroduces tree pruning for the initial FSM vacuum
>> 3 and 4 remain as they were, but reba
Claudio Freire writes:
> Attached patches, rebased and modified as discussed:
> 1 no longer does tree pruning, it just vacuums a range of the FSM
> 2 reintroduces tree pruning for the initial FSM vacuum
> 3 and 4 remain as they were, but rebased
I reviewed and cleaned up 0001. The API for FreeSp
On Mon, Mar 26, 2018 at 2:46 PM, Claudio Freire wrote:
> On Mon, Mar 26, 2018 at 11:26 AM, Claudio Freire
> wrote:
>> On Mon, Mar 26, 2018 at 11:19 AM, Tom Lane wrote:
>>> Claudio Freire writes:
On Sat, Mar 24, 2018 at 4:17 PM, Tom Lane wrote:
> I hadn't paid any attention to this pa
On Mon, Mar 26, 2018 at 11:26 AM, Claudio Freire wrote:
> On Mon, Mar 26, 2018 at 11:19 AM, Tom Lane wrote:
>> Claudio Freire writes:
>>> On Sat, Mar 24, 2018 at 4:17 PM, Tom Lane wrote:
I hadn't paid any attention to this patch previously, so maybe I'm
missing something ... but this
On Mon, Mar 26, 2018 at 11:19 AM, Tom Lane wrote:
> Claudio Freire writes:
>> On Sat, Mar 24, 2018 at 4:17 PM, Tom Lane wrote:
>>> I hadn't paid any attention to this patch previously, so maybe I'm
>>> missing something ... but this sure seems like a very bizarre approach
>>> to the problem. If
Claudio Freire writes:
> On Sat, Mar 24, 2018 at 4:17 PM, Tom Lane wrote:
>> I hadn't paid any attention to this patch previously, so maybe I'm
>> missing something ... but this sure seems like a very bizarre approach
>> to the problem. If the idea is to fix the FSM's upper levels after
>> vacuu
On Sat, Mar 24, 2018 at 4:17 PM, Tom Lane wrote:
> Claudio Freire writes:
>> [ 0001-Vacuum-Update-FSM-more-frequently-v9.patch ]
>
> I hadn't paid any attention to this patch previously, so maybe I'm
> missing something ... but this sure seems like a very bizarre approach
> to the problem. If th
On Sun, Mar 25, 2018 at 12:47 AM, Tom Lane wrote:
> Claudio Freire writes:
>> [ 0001-Vacuum-Update-FSM-more-frequently-v9.patch ]
>
> I hadn't paid any attention to this patch previously, so maybe I'm
> missing something ... but this sure seems like a very bizarre approach
> to the problem. If t
Claudio Freire writes:
> [ 0001-Vacuum-Update-FSM-more-frequently-v9.patch ]
I hadn't paid any attention to this patch previously, so maybe I'm
missing something ... but this sure seems like a very bizarre approach
to the problem. If the idea is to fix the FSM's upper levels after
vacuuming a kn
On Sun, Mar 4, 2018 at 10:25 PM, Masahiko Sawada wrote:
> On Mon, Mar 5, 2018 at 10:21 AM, Masahiko Sawada
> wrote:
>> On Fri, Mar 2, 2018 at 10:50 PM, Claudio Freire
>> wrote:
>>> On Fri, Mar 2, 2018 at 10:47 AM, Claudio Freire
>>> wrote:
On Fri, Mar 2, 2018 at 7:38 AM, Masahiko Sawada
On Mon, Mar 5, 2018 at 10:21 AM, Masahiko Sawada wrote:
> On Fri, Mar 2, 2018 at 10:50 PM, Claudio Freire
> wrote:
>> On Fri, Mar 2, 2018 at 10:47 AM, Claudio Freire
>> wrote:
>>> On Fri, Mar 2, 2018 at 7:38 AM, Masahiko Sawada
>>> wrote:
Thank you for updating the patches!
+/
On Fri, Mar 2, 2018 at 10:50 PM, Claudio Freire wrote:
> On Fri, Mar 2, 2018 at 10:47 AM, Claudio Freire
> wrote:
>> On Fri, Mar 2, 2018 at 7:38 AM, Masahiko Sawada
>> wrote:
>>> Thank you for updating the patches!
>>>
>>> +/*
>>> + * When a table has no indexes, vacuum the FSM at most every t
On Fri, Mar 2, 2018 at 10:47 AM, Claudio Freire wrote:
> On Fri, Mar 2, 2018 at 7:38 AM, Masahiko Sawada wrote:
>> Thank you for updating the patches!
>>
>> +/*
>> + * When a table has no indexes, vacuum the FSM at most every this
>> + * many dirty pages. With a default page size of 8kb, this val
On Fri, Mar 2, 2018 at 7:38 AM, Masahiko Sawada wrote:
> Thank you for updating the patches!
>
> +/*
> + * When a table has no indexes, vacuum the FSM at most every this
> + * many dirty pages. With a default page size of 8kb, this value
> + * basically means 8GB of dirtied pages.
> + */
> +#defin
On Wed, Feb 28, 2018 at 12:06 AM, Claudio Freire wrote:
> On Mon, Feb 26, 2018 at 10:20 PM, Masahiko Sawada
> wrote:
>> Thank you for updating patches!
>>
>> 0001 patch looks good to me except for the following unnecessary empty lines.
>>
>> +* If there are no indexes then we sho
On Tue, Feb 6, 2018 at 4:56 AM, Masahiko Sawada wrote:
> For vacuuming fsm of index, we might have to consider to
> vacuum fsm of index after lazy_vacuum_index.
I've been thinking about that, and I think you're right.
So here's a fourth patch that adds that to nbtree's bulkdelete implementation.
On Mon, Feb 26, 2018 at 10:20 PM, Masahiko Sawada wrote:
> Thank you for updating patches!
>
> 0001 patch looks good to me except for the following unnecessary empty lines.
>
> +* If there are no indexes then we should periodically
> vacuum the FSM
> +* on huge rela
On Tue, Feb 27, 2018 at 1:44 AM, Claudio Freire wrote:
> On Mon, Feb 26, 2018 at 1:32 PM, Claudio Freire
> wrote:
>> On Mon, Feb 26, 2018 at 11:31 AM, Claudio Freire
>> wrote:
>>> On Mon, Feb 26, 2018 at 6:00 AM, Masahiko Sawada
>>> wrote:
Here is review comment for v4 patch.
On Mon, Feb 26, 2018 at 1:32 PM, Claudio Freire wrote:
> On Mon, Feb 26, 2018 at 11:31 AM, Claudio Freire
> wrote:
>> On Mon, Feb 26, 2018 at 6:00 AM, Masahiko Sawada
>> wrote:
>>> Here is review comment for v4 patch.
>>>
>>> @@ -1922,6 +1988,8 @@ count_nondeletable_pages(Relation onerel,
>>>
On Mon, Feb 26, 2018 at 11:31 AM, Claudio Freire wrote:
> On Mon, Feb 26, 2018 at 6:00 AM, Masahiko Sawada
> wrote:
>> Here is review comment for v4 patch.
>>
>> @@ -1922,6 +1988,8 @@ count_nondeletable_pages(Relation onerel,
>> LVRelStats *vacrelstats)
>> * We don't insert a va
On Mon, Feb 26, 2018 at 11:31 AM, Claudio Freire wrote:
>>
>> + /*
>> +* If there are no indexes then we should periodically
>> vacuum the FSM
>> +* on huge relations to make free space visible early.
>> +*/
>> + if (
On Mon, Feb 26, 2018 at 6:00 AM, Masahiko Sawada wrote:
> Here is review comment for v4 patch.
>
> @@ -1922,6 +1988,8 @@ count_nondeletable_pages(Relation onerel,
> LVRelStats *vacrelstats)
> * We don't insert a vacuum delay point here, because we have
> an
> * e
On Tue, Feb 20, 2018 at 5:04 PM, Masahiko Sawada wrote:
> On Fri, Feb 16, 2018 at 5:00 AM, Claudio Freire
> wrote:
>> On Thu, Feb 15, 2018 at 4:47 PM, Claudio Freire
>> wrote:
>>> On Wed, Feb 14, 2018 at 3:59 AM, Masahiko Sawada
>>> wrote:
>>
> The final FSM vacuum pass isn't partial, to
On Fri, Feb 16, 2018 at 5:00 AM, Claudio Freire wrote:
> On Thu, Feb 15, 2018 at 4:47 PM, Claudio Freire
> wrote:
>> On Wed, Feb 14, 2018 at 3:59 AM, Masahiko Sawada
>> wrote:
>
The final FSM vacuum pass isn't partial, to finally correct all those
small inconsistencies.
>>>
>>> Yes,
On Thu, Feb 15, 2018 at 4:47 PM, Claudio Freire wrote:
> On Wed, Feb 14, 2018 at 3:59 AM, Masahiko Sawada
> wrote:
>>> The final FSM vacuum pass isn't partial, to finally correct all those
>>> small inconsistencies.
>>
>> Yes, but the purpose of this patch is to prevent table bloating from
>> c
On Wed, Feb 14, 2018 at 3:59 AM, Masahiko Sawada wrote:
> On Fri, Feb 9, 2018 at 11:48 PM, Claudio Freire
> wrote:
>> On Fri, Feb 9, 2018 at 1:36 AM, Masahiko Sawada
>> wrote:
>>> On Fri, Feb 9, 2018 at 12:45 AM, Claudio Freire
>>> wrote:
On Thu, Feb 8, 2018 at 1:36 AM, Masahiko Sawada
On Fri, Feb 9, 2018 at 11:48 PM, Claudio Freire wrote:
> On Fri, Feb 9, 2018 at 1:36 AM, Masahiko Sawada wrote:
>> On Fri, Feb 9, 2018 at 12:45 AM, Claudio Freire
>> wrote:
>>> On Thu, Feb 8, 2018 at 1:36 AM, Masahiko Sawada
>>> wrote:
On Tue, Feb 6, 2018 at 9:51 PM, Claudio Freire
>>>
On Fri, Feb 9, 2018 at 1:36 AM, Masahiko Sawada wrote:
> On Fri, Feb 9, 2018 at 12:45 AM, Claudio Freire
> wrote:
>> On Thu, Feb 8, 2018 at 1:36 AM, Masahiko Sawada
>> wrote:
>>> On Tue, Feb 6, 2018 at 9:51 PM, Claudio Freire
>>> wrote:
I can look into doing 3, that *might* get rid of t
On Fri, Feb 9, 2018 at 12:45 AM, Claudio Freire wrote:
> On Thu, Feb 8, 2018 at 1:36 AM, Masahiko Sawada wrote:
>> On Tue, Feb 6, 2018 at 9:51 PM, Claudio Freire
>> wrote:
>>> I can look into doing 3, that *might* get rid of the need to do that
>>> initial FSM vacuum, but all other intermediate
On Thu, Feb 8, 2018 at 1:36 AM, Masahiko Sawada wrote:
> On Tue, Feb 6, 2018 at 9:51 PM, Claudio Freire wrote:
>> I can look into doing 3, that *might* get rid of the need to do that
>> initial FSM vacuum, but all other intermediate vacuums are still
>> needed.
>
> Understood. So how about that t
On Tue, Feb 6, 2018 at 9:51 PM, Claudio Freire wrote:
> On Tue, Feb 6, 2018 at 4:56 AM, Masahiko Sawada wrote:
>> On Tue, Feb 6, 2018 at 2:55 AM, Claudio Freire
>> wrote:
>>> On Mon, Feb 5, 2018 at 1:53 AM, Masahiko Sawada
>>> wrote:
On Fri, Feb 2, 2018 at 11:13 PM, Claudio Freire
On Tue, Feb 6, 2018 at 7:51 AM, Claudio Freire wrote:
> No free space becomes visible during long-running vacuums. That means
> bloat keeps accumulating even though vacuum is freeing space, because
> the FSM doesn't expose that free space.
>
> The extra work incurred in those FSM vacuums isn't use
On Tue, Feb 6, 2018 at 4:56 AM, Masahiko Sawada wrote:
> On Tue, Feb 6, 2018 at 2:55 AM, Claudio Freire wrote:
>> On Mon, Feb 5, 2018 at 1:53 AM, Masahiko Sawada
>> wrote:
>>> On Fri, Feb 2, 2018 at 11:13 PM, Claudio Freire
>>> wrote:
After autovacuum gets cancelled, the next time it wak
On Tue, Feb 6, 2018 at 2:55 AM, Claudio Freire wrote:
> On Mon, Feb 5, 2018 at 1:53 AM, Masahiko Sawada wrote:
>> On Fri, Feb 2, 2018 at 11:13 PM, Claudio Freire
>> wrote:
>>> After autovacuum gets cancelled, the next time it wakes up it will
>>> retry vacuuming the cancelled relation. That's b
On Mon, Feb 5, 2018 at 2:55 PM, Claudio Freire wrote:
> With that in mind, I'm noticing WorkItems have a avw_database that
> isn't checked by do_autovacuum. Is that right? Shouldn't only work
> items that belong to the database being autovacuumed be processed?
NVM. I had to git pull, it's fixed i
On Mon, Feb 5, 2018 at 1:53 AM, Masahiko Sawada wrote:
> On Fri, Feb 2, 2018 at 11:13 PM, Claudio Freire
> wrote:
>> After autovacuum gets cancelled, the next time it wakes up it will
>> retry vacuuming the cancelled relation. That's because a cancelled
>> autovacuum doesn't update the last-vacu
On Fri, Feb 2, 2018 at 11:13 PM, Claudio Freire wrote:
> On Thu, Feb 1, 2018 at 9:34 PM, Masahiko Sawada wrote:
>> On Mon, Jan 29, 2018 at 11:31 PM, Claudio Freire
>> wrote:
>>> On Mon, Jan 29, 2018 at 4:12 AM, Masahiko Sawada
>>> wrote:
On Sat, Jul 29, 2017 at 9:42 AM, Claudio Freire
On Thu, Feb 1, 2018 at 9:34 PM, Masahiko Sawada wrote:
> On Mon, Jan 29, 2018 at 11:31 PM, Claudio Freire
> wrote:
>> On Mon, Jan 29, 2018 at 4:12 AM, Masahiko Sawada
>> wrote:
>>> On Sat, Jul 29, 2017 at 9:42 AM, Claudio Freire
>>> wrote:
Introduce a tree pruning threshold to FreeSpace
On Mon, Jan 29, 2018 at 11:31 PM, Claudio Freire wrote:
> On Mon, Jan 29, 2018 at 4:12 AM, Masahiko Sawada
> wrote:
>> On Sat, Jul 29, 2017 at 9:42 AM, Claudio Freire
>> wrote:
>>> Introduce a tree pruning threshold to FreeSpaceMapVacuum that avoids
>>> recursing into branches that already con
On Mon, Jan 29, 2018 at 4:12 AM, Masahiko Sawada wrote:
> On Sat, Jul 29, 2017 at 9:42 AM, Claudio Freire
> wrote:
>> Introduce a tree pruning threshold to FreeSpaceMapVacuum that avoids
>> recursing into branches that already contain enough free space, to
>> avoid having to traverse the whole F
On Sat, Jul 29, 2017 at 9:42 AM, Claudio Freire wrote:
> Introduce a tree pruning threshold to FreeSpaceMapVacuum that avoids
> recursing into branches that already contain enough free space, to
> avoid having to traverse the whole FSM and thus induce quadratic
> costs. Intermediate FSM vacuums ar
On Sat, Jan 6, 2018 at 7:33 PM, Stephen Frost wrote:
> Greetings Claudio,
>
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
> > On Mon, Nov 27, 2017 at 2:39 PM, Jing Wang
> wrote:
> > > A few general comments.
> > >
> > > + FreeSpaceMapVacuum(onerel, 64);
> > >
> > > Just want to know w
Greetings Claudio,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Mon, Nov 27, 2017 at 2:39 PM, Jing Wang wrote:
> > A few general comments.
> >
> > + FreeSpaceMapVacuum(onerel, 64);
> >
> > Just want to know why '64' is used here? It's better to give a description.
> >
> > +else
On Mon, Nov 27, 2017 at 2:39 PM, Jing Wang wrote:
> A few general comments.
>
> + FreeSpaceMapVacuum(onerel, 64);
>
> Just want to know why '64' is used here? It's better to give a description.
>
> +else
> + {
> + newslot = fsm_get_avail(page, 0);
> + }
>
> Since there is only one
A few general comments.
+ FreeSpaceMapVacuum(onerel, 64);
Just want to know why '64' is used here? It's better to give a description.
+else
+ {
+ newslot = fsm_get_avail(page, 0);
+ }
Since there is only one line in the else the bracket will not be needed.
And there in one more
51 matches
Mail list logo
