Re: Vacuum: allow usage of more than 1GB of work mem

From: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, Anastasia Lubennikova <lubennikovaav(at)gmail(dot)com>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Vacuum: allow usage of more than 1GB of work mem
Date: 2017-03-29 01:46:12
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Wed, Feb 1, 2017 at 7:55 PM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
> On Wed, Feb 1, 2017 at 6:13 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>> On Wed, Feb 1, 2017 at 10:02 PM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
>>> On Wed, Feb 1, 2017 at 5:47 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>>>> Thank you for updating the patch.
>>>> Whole patch looks good to me except for the following one comment.
>>>> This is the final comment from me.
>>>> /*
>>>> * lazy_tid_reaped() -- is a particular tid deletable?
>>>> *
>>>> * This has the right signature to be an IndexBulkDeleteCallback.
>>>> *
>>>> * Assumes dead_tuples array is in sorted order.
>>>> */
>>>> static bool
>>>> lazy_tid_reaped(ItemPointer itemptr, void *state)
>>>> {
>>>> LVRelStats *vacrelstats = (LVRelStats *) state;
>>>> You might want to update the comment of lazy_tid_reaped() as well.
>>> I don't see the mismatch with reality there (if you consider
>>> "dead_tples array" in the proper context, that is, the multiarray).
>>> What in particular do you find out of sync there?
>> The current lazy_tid_reaped just find a tid from a tid array using
>> bsearch but in your patch lazy_tid_reaped handles multiple tid arrays
>> and processing method become complicated. So I thought it's better to
>> add the description of this function.
> Alright, updated with some more remarks that seemed relevant

I just realized I never updated the early free patch after the
multiarray version.

So attached is a patch that frees the multiarray as early as possible
(just after finishing with index bulk deletes, right before doing
index cleanup and attempting truncation).

This should make the possibly big amount of memory available to other
processes for the duration of those tasks, which could be a long time
in some cases.

Attachment Content-Type Size
0003-Vacuum-free-dead-tuples-array-as-early-as-possible.patch text/x-patch 2.5 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2017-03-29 01:49:10 Re: Getting server crash after running sqlsmith
Previous Message Kyotaro HORIGUCHI 2017-03-29 01:40:07 Re: free space map and visibility map