Horton

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

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Claudio Freire <klaussfreire@gmail.com>
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-01-25T14:41:38Z
Lists: pgsql-hackers 
Claudio Freire wrote:
> On Thu, Jan 25, 2018 at 4:11 AM, Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:

> > *** 128,134 ****
> >   SELECT pg_relation_size('vactst', 'main');
> >    pg_relation_size
> >   ------------------
> > !                 0
> >   (1 row)
> >
> >   SELECT count(*) FROM vactst;
> > --- 128,134 ----
> >   SELECT pg_relation_size('vactst', 'main');
> >    pg_relation_size
> >   ------------------
> > !              8192
> >   (1 row)

> However, shouldn't an empty relation have an initial page anyway? In
> that case shouldn't the correct value be 8192?

No, it's legal for an empty table to have size 0 on disk.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Prefetch blocks during lazy vacuum's truncation scan

  2. Explain unaccounted for space in pgstattuple.