On Wed, May 8, 2019 at 02:14:04AM +0900, Fujii Masao wrote:
> On Tue, May 7, 2019 at 5:33 PM Masahiko Sawada wrote:
> > Sorry for the late. I've reviewed the patch and it looks good to me.
>
> Thanks for the review! I committed the patch.
Great. I noticed from the release notes that it was odd
On Mon, Apr 8, 2019 at 8:15 PM Julien Rouhaud wrote:
>
> On Mon, Apr 8, 2019 at 12:22 PM Fujii Masao wrote:
> >
> > On Mon, Apr 8, 2019 at 5:30 PM Masahiko Sawada
> > wrote:
> > >
> > > On Mon, Apr 8, 2019 at 5:15 PM Fujii Masao wrote:
> > > >
> > > > On Mon, Apr 8, 2019 at 3:58 PM Julien Rouh
On Tue, May 7, 2019 at 5:33 PM Masahiko Sawada wrote:
>
> On Mon, Apr 8, 2019 at 7:29 PM Masahiko Sawada wrote:
> >
> > On Mon, Apr 8, 2019 at 7:22 PM Fujii Masao wrote:
> > >
> > > On Mon, Apr 8, 2019 at 5:30 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Mon, Apr 8, 2019 at 5:15 PM Fujii
On Mon, Apr 8, 2019 at 7:29 PM Masahiko Sawada wrote:
>
> On Mon, Apr 8, 2019 at 7:22 PM Fujii Masao wrote:
> >
> > On Mon, Apr 8, 2019 at 5:30 PM Masahiko Sawada
> > wrote:
> > >
> > > On Mon, Apr 8, 2019 at 5:15 PM Fujii Masao wrote:
> > > >
> > > > On Mon, Apr 8, 2019 at 3:58 PM Julien Rouh
Hi,
On 2019-04-08 19:22:04 +0900, Fujii Masao wrote:
> On Mon, Apr 8, 2019 at 5:30 PM Masahiko Sawada wrote:
> > "TRUNCATE" option for vacuum command should be added to the open items?
>
> Yes, I think.
> Attached is the patch which adds TRUNCATE option into VACUUM.
This has been an open item f
At Wed, 10 Apr 2019 02:00:03 +0900, Fujii Masao wrote
in
> On Tue, Apr 9, 2019 at 1:07 PM Kyotaro HORIGUCHI
> wrote:
> >
> > Hello.
> >
> > At Mon, 8 Apr 2019 19:22:04 +0900, Fujii Masao
> > wrote in
> >
> > > > "TRUNCATE" option for vacuum command should be added to the open items?
> > >
>
On Tue, Apr 9, 2019 at 1:07 PM Kyotaro HORIGUCHI
wrote:
>
> Hello.
>
> At Mon, 8 Apr 2019 19:22:04 +0900, Fujii Masao wrote
> in
> > > "TRUNCATE" option for vacuum command should be added to the open items?
> >
> > Yes, I think.
> > Attached is the patch which adds TRUNCATE option into VACUUM.
Hello.
At Mon, 8 Apr 2019 19:22:04 +0900, Fujii Masao wrote in
> > "TRUNCATE" option for vacuum command should be added to the open items?
>
> Yes, I think.
> Attached is the patch which adds TRUNCATE option into VACUUM.
By the way, this might have been discussed upthread, but boolean
options
From: Fujii Masao [mailto:masao.fu...@gmail.com]
> Thanks for the info, so I marked the patch as committed.
Thanks a lot for your hard work! This felt relatively tough despite the
simplicity of the patch. I'm starting to feel the difficulty and fatigue in
developing in the community...
Regar
On Mon, Apr 8, 2019 at 10:24 AM Fujii Masao wrote:
>
> On Mon, Apr 8, 2019 at 5:20 PM Julien Rouhaud wrote:
> >
> > On Mon, Apr 8, 2019 at 10:15 AM Fujii Masao wrote:
> > >
> > > But it has not been actually pushed into the community's git
> > > repository yet.That's maybe because it's been a wh
On Mon, Apr 8, 2019 at 12:22 PM Fujii Masao wrote:
>
> On Mon, Apr 8, 2019 at 5:30 PM Masahiko Sawada wrote:
> >
> > On Mon, Apr 8, 2019 at 5:15 PM Fujii Masao wrote:
> > >
> > > On Mon, Apr 8, 2019 at 3:58 PM Julien Rouhaud wrote:
> > > >
> > > > On Mon, Apr 8, 2019 at 8:01 AM Fujii Masao
>
On Mon, Apr 8, 2019 at 7:22 PM Fujii Masao wrote:
>
> On Mon, Apr 8, 2019 at 5:30 PM Masahiko Sawada wrote:
> >
> > On Mon, Apr 8, 2019 at 5:15 PM Fujii Masao wrote:
> > >
> > > On Mon, Apr 8, 2019 at 3:58 PM Julien Rouhaud wrote:
> > > >
> > > > On Mon, Apr 8, 2019 at 8:01 AM Fujii Masao
> >
On Mon, Apr 8, 2019 at 5:30 PM Masahiko Sawada wrote:
>
> On Mon, Apr 8, 2019 at 5:15 PM Fujii Masao wrote:
> >
> > On Mon, Apr 8, 2019 at 3:58 PM Julien Rouhaud wrote:
> > >
> > > On Mon, Apr 8, 2019 at 8:01 AM Fujii Masao wrote:
> > > >
> > > > 2019年4月8日(月) 14:22 Tsunakawa, Takayuki :
> > > >
On Mon, Apr 8, 2019 at 5:15 PM Fujii Masao wrote:
>
> On Mon, Apr 8, 2019 at 3:58 PM Julien Rouhaud wrote:
> >
> > On Mon, Apr 8, 2019 at 8:01 AM Fujii Masao wrote:
> > >
> > > 2019年4月8日(月) 14:22 Tsunakawa, Takayuki :
> > >>
> > >> From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
> > >> >
On Mon, Apr 8, 2019 at 5:20 PM Julien Rouhaud wrote:
>
> On Mon, Apr 8, 2019 at 10:15 AM Fujii Masao wrote:
> >
> > OK, so I pushed the "vacuum_truncate" version of the patch.
>
> Thanks!
>
> > But it has not been actually pushed into the community's git
> > repository yet.That's maybe because it
On Mon, Apr 8, 2019 at 10:15 AM Fujii Masao wrote:
>
> OK, so I pushed the "vacuum_truncate" version of the patch.
Thanks!
> But it has not been actually pushed into the community's git
> repository yet.That's maybe because it's been a while since
> my last commit and my commit bit is temporaril
On Mon, Apr 8, 2019 at 3:58 PM Julien Rouhaud wrote:
>
> On Mon, Apr 8, 2019 at 8:01 AM Fujii Masao wrote:
> >
> > 2019年4月8日(月) 14:22 Tsunakawa, Takayuki :
> >>
> >> From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
> >> > "vacuum_truncate" gets my vote too.
> >>
> >> +1
> >
> >
> > +1
> > I
On Mon, Apr 8, 2019 at 8:01 AM Fujii Masao wrote:
>
> 2019年4月8日(月) 14:22 Tsunakawa, Takayuki :
>>
>> From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
>> > "vacuum_truncate" gets my vote too.
>>
>> +1
>
>
> +1
> ISTM that we have small consensus to
> use "vacuum_truncate".
I'm also fine with
2019年4月8日(月) 14:22 Tsunakawa, Takayuki :
> From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
> > "vacuum_truncate" gets my vote too.
>
> +1
>
+1
ISTM that we have small consensus to
use "vacuum_truncate".
regards,
From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
> "vacuum_truncate" gets my vote too.
+1
From: 'Andres Freund' [mailto:and...@anarazel.de]
> Personally I think the name just needs some committer to make a
> call. This largely is going to be used after encountering too many
> cancellations
On 2019-Apr-08, Tom Lane wrote:
> The closest match to that name, probably, is just "vacuum_truncate" ---
> which was proposed at the beginning of March, but apparently also
> rejected, because there's no subsequent reference.
"vacuum_truncate" gets my vote too.
--
Álvaro Herrera
On Mon, Apr 08, 2019 at 03:56:52AM +, Tsunakawa, Takayuki wrote:
> Consensus on the name seems to use truncate rather than shrink (a
> few poople kindly said they like shrink, and I'm OK with either
> name.) And there's no dispute on the behavior. Do you see any
> other point?
I personally m
Hi,
On 2019-04-08 00:38:44 -0400, Tom Lane wrote:
> "Tsunakawa, Takayuki" writes:
> > From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> >> And, as far as I can see from a quick review of the thread,
> >> we don't really have consensus on the names and behaviors.
Personally I think the name just needs
"Tsunakawa, Takayuki" writes:
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>> And, as far as I can see from a quick review of the thread,
>> we don't really have consensus on the names and behaviors.
> Consensus on the name seems to use truncate rather than shrink (a few poople
> kindly said the
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> And, as far as I can see from a quick review of the thread,
> we don't really have consensus on the names and behaviors.
Consensus on the name seems to use truncate rather than shrink (a few poople
kindly said they like shrink, and I'm OK with either n
"Tsunakawa, Takayuki" writes:
> From: Andres Freund [mailto:and...@anarazel.de]
>> I hope you realize feature freeze is in a few hours...
> Ouch! Could you take care of committing the patch, please? I wouldn't be
> able to express the sadness and tiredness just in case this is pushed to 13
>
Hi Andres, Fujii-san, any committer,
From: Andres Freund [mailto:and...@anarazel.de]
> On 2019-04-08 09:52:27 +0900, Fujii Masao wrote:
> > I'm thinking to commit this patch at first. We can change the term
> > and add the support of "TRUNCATE" option for VACUUM command later.
>
> I hope you rea
Hi,
On 2019-04-08 09:52:27 +0900, Fujii Masao wrote:
> I'm thinking to commit this patch at first. We can change the term
> and add the support of "TRUNCATE" option for VACUUM command later.
I hope you realize feature freeze is in a few hours...
Greetings,
Andres Freund
On Mon, Apr 8, 2019 at 9:52 AM Fujii Masao wrote:
>
> On Sat, Apr 6, 2019 at 2:04 AM Robert Haas wrote:
> >
> > On Thu, Apr 4, 2019 at 9:19 PM Masahiko Sawada
> > wrote:
> > > As INDEX_CLEANUP option has been added by commit a96c41f, the new
> > > option for this feature could also accept zero
On Sat, Apr 6, 2019 at 2:04 AM Robert Haas wrote:
>
> On Thu, Apr 4, 2019 at 9:19 PM Masahiko Sawada wrote:
> > As INDEX_CLEANUP option has been added by commit a96c41f, the new
> > option for this feature could also accept zero or one boolean
> > argument, that is SHRINK_TABLE [true|false] and t
On Fri, Apr 5, 2019 at 3:28 PM Robert Haas wrote:
>
> On Fri, Apr 5, 2019 at 2:11 PM Julien Rouhaud wrote:
> > > My preference is for "truncate" over "shrink".
> >
> > I don't really like "shrink" either, but users already have problems
> > to get the difference between VACUUM and VACUUM FULL, I'
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
I have read disable-vacuum-truncation_v6.patch.
I like it the way it is.
Wo
On Fri, Apr 5, 2019 at 3:28 PM Adrien Mobile wrote:
> How about TRIM?
The problem, in my view, is not that there is anything ipso facto
wrong with SHRINK. The problem is that it's a turn term that has only
de minimis use up until now. Replacing it with some other term that
has never before been
Le 5 avril 2019 20:11:38 GMT+02:00, Julien Rouhaud a écrit
:
>On Fri, Apr 5, 2019 at 7:04 PM Robert Haas
>wrote:
>>
>
>> My preference is for "truncate" over "shrink".
>
>I don't really like "shrink" either, but users already have problems
>to get the difference between VACUUM and VACUUM FULL, I
On Fri, Apr 5, 2019 at 2:11 PM Julien Rouhaud wrote:
> > My preference is for "truncate" over "shrink".
>
> I don't really like "shrink" either, but users already have problems
> to get the difference between VACUUM and VACUUM FULL, I'm afraid that
> "VACUUM TRUNCATE_TABLE" will just make things w
On Fri, Apr 5, 2019 at 7:04 PM Robert Haas wrote:
>
> On Thu, Apr 4, 2019 at 9:19 PM Masahiko Sawada wrote:
> > As INDEX_CLEANUP option has been added by commit a96c41f, the new
> > option for this feature could also accept zero or one boolean
> > argument, that is SHRINK_TABLE [true|false] and t
On Thu, Apr 4, 2019 at 9:19 PM Masahiko Sawada wrote:
> As INDEX_CLEANUP option has been added by commit a96c41f, the new
> option for this feature could also accept zero or one boolean
> argument, that is SHRINK_TABLE [true|false] and true by default.
> Explicit options on VACUUM command overwrit
On Thu, Apr 4, 2019 at 10:07 PM Julien Rouhaud wrote:
>
> On Thu, Apr 4, 2019 at 1:23 PM Masahiko Sawada wrote:
> >
> > On Thu, Apr 4, 2019 at 1:26 PM Tsunakawa, Takayuki
> > wrote:
> > >
> > > From: Fujii Masao [mailto:masao.fu...@gmail.com]
> > > > reloption for TOAST is also required?
> > >
>
From: Masahiko Sawada [mailto:sawada.m...@gmail.com]
> "VACUUM" needs or "vacuum" is more appropriate here?
Looking at the same file and some other files, "vacuum" looks appropriate
because it represents the vacuum action, not the specific VACUUM command.
> The format of the documentation of n
On Thu, Apr 4, 2019 at 1:23 PM Masahiko Sawada wrote:
>
> On Thu, Apr 4, 2019 at 1:26 PM Tsunakawa, Takayuki
> wrote:
> >
> > From: Fujii Masao [mailto:masao.fu...@gmail.com]
> > > reloption for TOAST is also required?
> >
> > # I've come back to the office earlier than planned...
> >
> > Hm, the
On Thu, Apr 4, 2019 at 1:26 PM Tsunakawa, Takayuki
wrote:
>
> From: Fujii Masao [mailto:masao.fu...@gmail.com]
> > reloption for TOAST is also required?
>
> # I've come back to the office earlier than planned...
>
> Hm, there's no reason to not provide toast.vacuum_shrink_enabled. Done with
> th
From: Fujii Masao [mailto:masao.fu...@gmail.com]
> reloption for TOAST is also required?
# I've come back to the office earlier than planned...
Hm, there's no reason to not provide toast.vacuum_shrink_enabled. Done with
the attached patch.
Regards
Takayuki Tsunakawa
disable-vacuum-truncat
On Thu, Mar 28, 2019 at 11:45 AM Tsunakawa, Takayuki
wrote:
>
> From: Robert Haas [mailto:robertmh...@gmail.com]
> > You're both right and I'm wrong.
> >
> > However, I think it would be better to stick with the term 'truncate'
> > which is widely-used already, rather than introducing a new term.
From: Robert Haas [mailto:robertmh...@gmail.com]
> You're both right and I'm wrong.
>
> However, I think it would be better to stick with the term 'truncate'
> which is widely-used already, rather than introducing a new term.
Yeah, I have the same feeling. OTOH, as I referred in this thread, shr
On Tue, Mar 26, 2019 at 10:35 PM Tsunakawa, Takayuki
wrote:
> I almost have the same view as Sawada-san. The reloption
> vacuum_shrink_enabled is a positive name and follows the naming style of
> other reloptions. I hope this matches the style you have in mind.
You're both right and I'm wrong
From: Masahiko Sawada [mailto:sawada.m...@gmail.com]
> On Wed, Mar 27, 2019 at 2:30 AM Robert Haas wrote:
> >
> > On Tue, Mar 26, 2019 at 11:23 AM Masahiko Sawada
> wrote:
> > > > I don't see a patch with the naming updated, here or there, and I'm
> > > > going to be really unhappy if we end up w
On Wed, Mar 27, 2019 at 2:30 AM Robert Haas wrote:
>
> On Tue, Mar 26, 2019 at 11:23 AM Masahiko Sawada
> wrote:
> > > I don't see a patch with the naming updated, here or there, and I'm
> > > going to be really unhappy if we end up with inconsistent naming
> > > between two patches that do such
On Tue, Mar 26, 2019 at 11:23 AM Masahiko Sawada wrote:
> > I don't see a patch with the naming updated, here or there, and I'm
> > going to be really unhappy if we end up with inconsistent naming
> > between two patches that do such fundamentally similar things. -1
> > from me to committing eith
On Tue, Mar 26, 2019 at 10:30 PM Robert Haas wrote:
>
> On Tue, Mar 26, 2019 at 3:57 AM Tsunakawa, Takayuki
> wrote:
> > From: David Steele [mailto:da...@pgmasters.net]
> > > This patch appears to have been stalled for a while.
> > >
> > > Takayuki -- the ball appears to be in your court. Perhap
On Tue, Mar 26, 2019 at 3:57 AM Tsunakawa, Takayuki
wrote:
> From: David Steele [mailto:da...@pgmasters.net]
> > This patch appears to have been stalled for a while.
> >
> > Takayuki -- the ball appears to be in your court. Perhaps it would be
> > helpful to summarize what you think are next step
From: David Steele [mailto:da...@pgmasters.net]
> This patch appears to have been stalled for a while.
>
> Takayuki -- the ball appears to be in your court. Perhaps it would be
> helpful to summarize what you think are next steps?
disable_index_cleanup is handled by Sawada-san in another thread.
On 3/5/19 6:41 AM, Masahiko Sawada wrote:
I understood the use case. I'm inclined to add DISABLE_INDEX_CLEANUP
as a reloption.
It's an improvement but it seems to me that the specifying a threshold
or scale factor would be more useful for that case than just turning
on and off. It's something l
On Tue, Mar 5, 2019 at 5:11 AM Andres Freund wrote:
>
> Hi,
>
> On 2019-03-04 20:03:37 +, Bossart, Nathan wrote:
> > On 3/3/19, 9:23 PM, "Masahiko Sawada" wrote:
> > > FWIW, I agree that we have options for vacuum as vacuum
> > > command options. But for reloptions, I think if the persistence
On 3/4/19, 2:05 PM, "Andres Freund" wrote:
> On 2019-03-04 22:00:47 +, Bossart, Nathan wrote:
>> On 3/4/19, 1:44 PM, "Andres Freund" wrote:
>> > Yea, I do think that's a danger. But we allow disabling autovacuum, so
>> > I'm not sure it matters that much... And for indexes you'd still have
>>
Hi,
On 2019-03-04 22:00:47 +, Bossart, Nathan wrote:
> On 3/4/19, 1:44 PM, "Andres Freund" wrote:
> > Yea, I do think that's a danger. But we allow disabling autovacuum, so
> > I'm not sure it matters that much... And for indexes you'd still have
> > the index page-level vacuum that'd continu
On 3/4/19, 1:44 PM, "Andres Freund" wrote:
> On 2019-03-04 21:40:53 +, Bossart, Nathan wrote:
>> On 3/4/19, 12:11 PM, "Andres Freund" wrote:
>> > I'm not quite convinced this is right. There's plenty sites that
>> > practically can't use autovacuum because it might decide to vacuum the
>> >
Hi,
On 2019-03-04 21:40:53 +, Bossart, Nathan wrote:
> On 3/4/19, 12:11 PM, "Andres Freund" wrote:
> > I'm not quite convinced this is right. There's plenty sites that
> > practically can't use autovacuum because it might decide to vacuum the
> > 5TB index because of 300 dead tuples in the m
On 3/4/19, 12:11 PM, "Andres Freund" wrote:
> I'm not quite convinced this is right. There's plenty sites that
> practically can't use autovacuum because it might decide to vacuum the
> 5TB index because of 300 dead tuples in the middle of busy periods. And
> without an reloption that's not cont
Hi,
On 2019-03-04 20:03:37 +, Bossart, Nathan wrote:
> On 3/3/19, 9:23 PM, "Masahiko Sawada" wrote:
> > FWIW, I agree that we have options for vacuum as vacuum
> > command options. But for reloptions, I think if the persistence the
> > setting could be problematic we should not. According to
On 3/3/19, 9:23 PM, "Masahiko Sawada" wrote:
> FWIW, I agree that we have options for vacuum as vacuum
> command options. But for reloptions, I think if the persistence the
> setting could be problematic we should not. According to the
> discussions so far, I think VACUUM_SHRINK_ENABLED is the one
On Sat, Mar 2, 2019 at 4:34 AM Tom Lane wrote:
>
> Andrew Dunstan writes:
> > On 3/1/19 2:14 PM, Tom Lane wrote:
> >> Indeed, but I'm not sure that the use-cases are the same. In particular,
> >> unless somebody has done some rather impossible magic, it would be
> >> disastrous to apply DISABLE_
Andrew Dunstan writes:
> On 3/1/19 2:14 PM, Tom Lane wrote:
>> Indeed, but I'm not sure that the use-cases are the same. In particular,
>> unless somebody has done some rather impossible magic, it would be
>> disastrous to apply DISABLE_INDEX_CLEANUP as a reloption, because then
>> it would be pe
Andres Freund writes:
> On 2019-03-01 14:17:33 -0500, Tom Lane wrote:
>> I think we should reject the whole patch, tbh, and go do something
>> about the underlying problem instead. Once we've made truncation
>> not require AEL, this will be nothing but a legacy wart that we'll
>> have a hard time
On 3/1/19 2:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> I want to make one other point about this patch, which is that over on
>> the thread "New vacuum option to do only freezing" we have a patch
>> that does a closely-related thing. Both patches skip one phase of the
>> overall VACUUM pro
Hi,
On 2019-03-01 14:17:33 -0500, Tom Lane wrote:
> Andres Freund writes:
> > OTOH, as the main reason for wanting to disable truncation is that a
> > user is getting very undesirable HS conflicts, it doesn't seem right to
> > force them to change the reloption on all tables, and then somehow for
Andres Freund writes:
> OTOH, as the main reason for wanting to disable truncation is that a
> user is getting very undesirable HS conflicts, it doesn't seem right to
> force them to change the reloption on all tables, and then somehow force
> it to be set on all tables created at a later stage. I
Robert Haas writes:
> I want to make one other point about this patch, which is that over on
> the thread "New vacuum option to do only freezing" we have a patch
> that does a closely-related thing. Both patches skip one phase of the
> overall VACUUM process. THIS patch wants to skip truncation;
Hi,
On 2019-02-27 10:55:49 -0500, Robert Haas wrote:
> I don't think that a VACUUM option would be out of place, but a GUC
> sounds like an attractive nuisance to me. It will encourage people to
> just flip it blindly instead of considering the particular cases where
> they need that behavior, an
On 3/1/19 1:43 PM, Robert Haas wrote:
> On Thu, Feb 28, 2019 at 3:17 AM Tsunakawa, Takayuki
> wrote:
>> Uh, thanks. I've just recognized I didn't know the meaning of "nuisance."
>> I've looked up the meaning in the dictionary. Nuisance is like a trouble
>> maker...
> My proposal would be th
On Thu, Feb 28, 2019 at 3:17 AM Tsunakawa, Takayuki
wrote:
> Uh, thanks. I've just recognized I didn't know the meaning of "nuisance."
> I've looked up the meaning in the dictionary. Nuisance is like a trouble
> maker...
Yes, and "attractive nuisance" means something that, superficially, it
Alvaro Herrera writes:
> On 2019-Feb-28, Tom Lane wrote:
>> I wasn't really working on that for v12 --- I figured it was way
>> too late in the cycle to be starting on such a significant change.
> Oh, well, it certainly seems far too late *now*. However, what about
> the idea in
> https://postg
On 2019-Feb-28, Tom Lane wrote:
> Alvaro Herrera writes:
> > Hopefully we'll get Tom's patch that addresses the failure-to-truncate
> > issues in pg12.
>
> Hm, are you speaking of the handwaving I did in
> https://www.postgresql.org/message-id/2348.1544474...@sss.pgh.pa.us
> ?
>
> I wasn't real
Tsunakawa, Takayuki wrote:
> Why do you think that it's better for VACUUM command to have the option? I
> think it's a
> table property whose value is determined based on the application workload,
> not per VACUUM
> execution. Rather, I think GUC is more useful to determine the behavior of
> t
From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
> Robert used the phrase "attractive nuisance", which maybe sounds like a
> good thing to have to a non native speaker, but it actually isn't -- he
> was saying we should avoid a GUC at all, and I can see the reason for
> that. I think we shou
Hi
> The default should always be to shrink, unless either the VACUUM
> option or the reloption turn that off. (So it doesn't make sense to set
> either the VACUUM option or the reloption to "on").
I think VACUUM option can be set to "on" by hand in order to override reloption
only for this VACU
Alvaro Herrera wrote:
> I think we should have a VACUUM option and a reloption, but no
> GUC. The default should always be to shrink, unless either the VACUUM
> option or the reloption turn that off. (So it doesn't make sense to set
> either the VACUUM option or the reloption to "on").
+1
Yours
Alvaro Herrera writes:
> Hopefully we'll get Tom's patch that addresses the failure-to-truncate
> issues in pg12.
Hm, are you speaking of the handwaving I did in
https://www.postgresql.org/message-id/2348.1544474...@sss.pgh.pa.us
?
I wasn't really working on that for v12 --- I figured it was way
On 2019-Feb-28, Tsunakawa, Takayuki wrote:
> From: Michael Paquier [mailto:mich...@paquier.xyz]
> > So we could you consider adding an option for the VACUUM command as well
> > as vacuumdb? The interactions with the current patch is that you need to
> > define the behavior at the beginning of vac
From: Michael Paquier [mailto:mich...@paquier.xyz]
> So we could you consider adding an option for the VACUUM command as well
> as vacuumdb? The interactions with the current patch is that you need to
> define the behavior at the beginning of vacuum for a given heap, instead
> of reading the param
On Thu, Feb 28, 2019 at 01:05:07AM +, Tsunakawa, Takayuki wrote:
> From: Robert Haas [mailto:robertmh...@gmail.com]
>> I don't think that a VACUUM option would be out of place, but a GUC
>> sounds like an attractive nuisance to me. It will encourage people to
>> just flip it blindly instead of
From: Robert Haas [mailto:robertmh...@gmail.com]
> I don't think that a VACUUM option would be out of place, but a GUC
> sounds like an attractive nuisance to me. It will encourage people to
> just flip it blindly instead of considering the particular cases where
> they need that behavior, and I t
From: Michael Paquier [mailto:mich...@paquier.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 bas
On Mon, Feb 25, 2019 at 4:25 AM Michael Paquier wrote:
> 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 autovac
On Tue, Feb 26, 2019 at 3:29 PM Tsunakawa, Takayuki
wrote:
>
> From: Masahiko Sawada [mailto:sawada.m...@gmail.com]
> > This test expects that the inserted tuple is always reclaimed by
> > subsequent vacuum, but it's not always true if there are concurrent
> > transactions. So size of the reloptio
From: Masahiko Sawada [mailto:sawada.m...@gmail.com]
> This test expects that the inserted tuple is always reclaimed by
> subsequent vacuum, but it's not always true if there are concurrent
> transactions. So size of the reloptions_test table will not be 0 if
> the tuple is not vacuumed. In my envi
On Mon, Feb 25, 2019 at 7:01 PM Tsunakawa, Takayuki
wrote:
>
> From: Michael Paquier [mailto:mich...@paquier.xyz]
> On Mon, Feb 25, 2019 at 03:59:21PM +0900, Masahiko Sawada wrote:
> > > Also, I think that this test may fail in case where concurrent
> > > transactions are running. So maybe should
From: Michael Paquier [mailto:mich...@paquier.xyz]
On Mon, Feb 25, 2019 at 03:59:21PM +0900, Masahiko Sawada wrote:
> > Also, I think that this test may fail in case where concurrent
> > transactions are running. So maybe should not run it in parallel to
> > other tests.
>
> That's why autovacuum
On Mon, Feb 25, 2019 at 08:47:28AM +0100, Julien Rouhaud wrote:
> Ah good point. We could also use something like
> pg_relation_size('reloptions_test') /
> current_setting('block_size')::bigint but >0 should be enough for this
> test.
Also, shouldn't the relopt check happen in
should_attempt_trun
On Mon, Feb 25, 2019 at 03:59:21PM +0900, Masahiko Sawada wrote:
> Also, I think that this test may fail in case where concurrent
> transactions are running. So maybe should not run it in parallel to
> other tests.
That's why autovacuum is disabled in this specific test, no? A
comment may be a go
On Mon, Feb 25, 2019 at 7:56 AM Michael Paquier wrote:
>
> On Mon, Feb 25, 2019 at 02:38:05AM +, Tsunakawa, Takayuki wrote:
> > From: Julien Rouhaud [mailto:rjuju...@gmail.com]
> >> One last thing, I think we should at least add one regression test for
> >> this setting. The one you provided
On Mon, Feb 25, 2019 at 3:56 PM Michael Paquier wrote:
>
> On Mon, Feb 25, 2019 at 02:38:05AM +, Tsunakawa, Takayuki wrote:
> > From: Julien Rouhaud [mailto:rjuju...@gmail.com]
> >> One last thing, I think we should at least add one regression test for
> >> this setting. The one you provided
On Mon, Feb 25, 2019 at 02:38:05AM +, Tsunakawa, Takayuki wrote:
> From: Julien Rouhaud [mailto:rjuju...@gmail.com]
>> One last thing, I think we should at least add one regression test for
>> this setting. The one you provided previously seems perfectly suited.
>
> Thanks, added.
+SELECT pg
From: Michael Paquier [mailto:mich...@paquier.xyz]
> I don't think that we want to use a too generic name and it seems more natural
> to reflect the context where it is used in the parameter name.
> If we were to shrink with a similar option for other contexts, we would
> most likely use a differen
On Fri, Feb 22, 2019 at 3:39 AM Tsunakawa, Takayuki
wrote:
>
> No, changing the parameter acquires ShareUpdaeExclusive lock. I just
> imitated the description for n_distinct in the same comment block. The
> meaning is that the setting cannot be changed during VACUUM, so in-flight
> VACUUM is
On Fri, Feb 22, 2019 at 02:38:56AM +, Tsunakawa, Takayuki wrote:
> From: Julien Rouhaud [mailto:rjuju...@gmail.com]
>> FWIW, I prefer shrink over truncate, though I'd rather go with
>> vacuum_shink_enabled as suggested previously.
>
> Thanks. I'd like to leave a committer to choose the name.
From: Julien Rouhaud [mailto:rjuju...@gmail.com]
> FWIW, I prefer shrink over truncate, though I'd rather go with
> vacuum_shink_enabled as suggested previously.
Thanks. I'd like to leave a committer to choose the name. FWIW, I chose
shrink_enabled rather than vacuum_shrink_enabled because this
Hi,
On Mon, Feb 4, 2019 at 1:25 AM Tsunakawa, Takayuki
wrote:
>
> FYI, it seems that the user sees "shrink" rather than "truncate" in the
> documentation as below, although these are about VACUUM FULL.
>
> https://www.postgresql.org/docs/devel/sql-vacuum.html
> would like the table to physically
From: Michael Paquier [mailto:mich...@paquier.xyz]
> On Fri, Feb 01, 2019 at 09:11:50AM +0100, Laurenz Albe wrote:
> > Perhaps "vacuum_shrink_enabled" would be even better.
>
> Naming it just vacuum_truncate and autovacuum_truncate (with aliases for
> toast and such), looks more natural to me. "s
On Fri, Feb 01, 2019 at 09:11:50AM +0100, Laurenz Albe wrote:
> Jamison, Kirk wrote:
>> I wonder if there is a better reloption name for
>> shrink_enabled. (truncate_enabled, vacuum_enabled? Hmm. No?)
>> On the other hand, shrink_enabled seems to describe well what it's
>> supposed to do when vac
Jamison, Kirk wrote:
> On February 1, 2019, Tsunakawa, Takayuki wrote:
>
> > > As most people seem to agree adding the reloption, here's the patch.
> > > It passes make check, and works like this:
> > Sorry, I forgot to include the modified header file. Revised patch
> > attached.
>
> I wond
1 - 100 of 131 matches
Mail list logo
