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
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,
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
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,
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
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
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
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
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,
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
>
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
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,
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
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
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
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
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.
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
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
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
23 matches
Mail list logo
