|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|
|Views:||Raw Message | Whole Thread | Download mbox|
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
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.
|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|