RE: reloption to prevent VACUUM from truncating empty pages at the end of relation

From: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>, 'Masahiko Sawada' <sawada(dot)mshk(at)gmail(dot)com>
Cc: Julien Rouhaud <rjuju123(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, "Jamison, Kirk" <k(dot)jamison(at)jp(dot)fujitsu(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: reloption to prevent VACUUM from truncating empty pages at the end of relation
Date: 2019-02-28 00:48:18
Message-ID: 0A3221C70F24FB45833433255569204D1FBBA3F6@G01JPEXMBYT05
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

From: Michael Paquier [mailto:michael(at)paquier(dot)xyz]
> This makes the test page-size sensitive. While we don't ensure that tests
> can be run with different page sizes, we should make a maximum effort to
> keep the tests compatible if that's easy enough. In this case you could
> just use > 0 as base comparison. I can fix that by myself, so no need to
> send a new version.

Good idea. Done.

> Should we also document that the parameter is effective for autovacuum?
> The name can lead to confusion regarding that.

I'm not sure for the need because autovacuum is just an automatic execution of vacuum, and existing vacuum_xxx parameters also apply to autovacuum. But being specific is good anyway, so I added reference to autovacuum in the description.

> Also, shouldn't the relopt check happen in should_attempt_truncation()?
> It seems to me that if we use this routine somewhere else then it should
> be controlled by the option.

That makes sense. Done.

> At the same time, we also have REL_TRUNCATE_FRACTION and
> REL_TRUNCATE_MINIMUM which could be made equally user-tunnable.
> That's more difficult to control, still why don't we also consider this
> part?

I thought of it, too. But I didn't have a good idea on how to explain those parameters. I'd like to separate it.

> Another thing that seems worth thinking about is a system-level GUC, and
> an option in the VACUUM command to control if truncation should happen or
> not. We have a lot of infrastructure to control such options between vacuum
> and autovacuum, so it could be a waste to not consider potential synergies.

Being able to specify this parameter in postgresql.conf and SET (especially ALTER DATABASE/USER to target specific databases/applications) might be useful, but I'm not sure... I'm less confident about whether VACUUM command can specify this, because this is a property of table under a specific workload, not a changable property of each VACUUM action. Anyway, I expect it won't be difficult to add those configurability without contradicting the design, so I'm inclined to separate it.

From: Masahiko Sawada [mailto:sawada(dot)mshk(at)gmail(dot)com]
> Yeah, that would work. Or it's kind of hackie but the rolling back the
> insertion instead of INSERT and DELETE might also work.

That's good, because it allows us to keep running reloptions test in parallel with other tests. Done.

Regards
Takayuki Tsunakawa

Attachment Content-Type Size
disable-vacuum-truncation_v4.patch application/octet-stream 8.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-02-28 00:49:59 Re: get_controlfile() can leak fds in the backend
Previous Message Joe Conway 2019-02-28 00:45:11 Re: get_controlfile() can leak fds in the backend