Horton

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

Claudio Freire <klaussfreire@gmail.com>

View thread View on postgr.es
From: Claudio Freire <klaussfreire@gmail.com>
To: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>, Stephen Frost <sfrost@snowman.net>, Michael Paquier <michael.paquier@gmail.com>, Daniel Gustafsson <daniel@yesql.se>, Andres Freund <andres@anarazel.de>, Masahiko Sawada <sawada.mshk@gmail.com>, Anastasia Lubennikova <a.lubennikova@postgrespro.ru>, Anastasia Lubennikova <lubennikovaav@gmail.com>, PostgreSQL-Dev <pgsql-hackers@postgresql.org>
Date: 2018-02-06T13:18:05Z
Lists: pgsql-hackers 
On Tue, Feb 6, 2018 at 4:35 AM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:
>> It's starting to look like a timing effect indeed.
>
> It seems to be truncation skip, maybe caused by concurrent
> autovacuum.

Good point, I'll also disable autovacuum on vactst.

> See lazy_truncate_heap() for details. Updates of
> pg_stat_*_tables can be delayed so looking it also can fail. Even
> though I haven't looked the patch closer, the "SELECT
> pg_relation_size()" doesn't seem to give something meaningful
> anyway.

Maybe then "explain (analyze, buffers, costs off, timing off, summary
off) select * from vactst" then.

The point is to check that the relation's heap has 0 pages.

Commits

  1. Prefetch blocks during lazy vacuum's truncation scan

  2. Explain unaccounted for space in pgstattuple.