On 2/8/21, 9:19 PM, "Michael Paquier" wrote:
> On Mon, Feb 08, 2021 at 06:59:45PM +, Bossart, Nathan wrote:
>> These suggestions seem reasonable to me. I've applied them in v9.
>
> Sounds good to me, so applied.
Thanks!
Nathan
On Mon, Feb 08, 2021 at 06:59:45PM +, Bossart, Nathan wrote:
> These suggestions seem reasonable to me. I've applied them in v9.
Sounds good to me, so applied.
--
Michael
signature.asc
Description: PGP signature
On Mon, Feb 08, 2021 at 04:35:19PM +0900, Michael Paquier wrote:
> On Fri, Jan 29, 2021 at 06:43:44PM +, Bossart, Nathan wrote:
> > I changed it to PROCESS_TOAST.
>
> Thanks. PROCESS_TOAST sounds good to me at the end for the option
> name, so let's just go with that.
>
> > Done.
>
> While
On Fri, Jan 29, 2021 at 06:43:44PM +, Bossart, Nathan wrote:
> I changed it to PROCESS_TOAST.
Thanks. PROCESS_TOAST sounds good to me at the end for the option
name, so let's just go with that.
> Done.
While on it, I could not resist with changing VACOPT_SKIPTOAST to
VACOPT_PROCESS_TOAST on
On Thu, Jan 28, 2021 at 06:16:09PM +, Bossart, Nathan wrote:
> I chose TOAST_TABLE_CLEANUP to match the INDEX_CLEANUP option, but I'm
> not wedded to that name. What do you think about PROCESS_TOAST_TABLE?
Most of the other options use a verb, so using PROCESS, or even SKIP
sounds like a good
On 1/27/21, 5:08 PM, "Justin Pryzby" wrote:
> Thanks, I wrote my message after running into the issue and remembered this
> thread. I didn't necessarily mean to send another patch :)
No worries. I lost track of this thread, but I don't mind picking it
up again.
> My only comment is on the name
On Wed, Jan 27, 2021 at 11:16:26PM +, Bossart, Nathan wrote:
> On 1/27/21, 11:07 AM, "Justin Pryzby" wrote:
> > This just came up for me:
> >
> > I have a daily maintenance script which pro-actively vacuums tables:
> > freezing
> > historic partitions, vacuuming current tables if the table's
On Fri, Jan 24, 2020 at 09:24:45PM +, Bossart, Nathan wrote:
> On 1/21/20, 1:39 PM, "Vik Fearing" wrote:
> > On 21/01/2020 22:21, Bossart, Nathan wrote:
> >> I've attached a patch for a couple of new options for VACUUM:
> >> MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP. The motive
> >
On Thu, Aug 06, 2020 at 11:50:06AM +0900, Michael Paquier wrote:
> True that you need an extra GRANT USAGE ON pg_toast to achieve that
> for users with no privileges, but that's not impossible now either. I
> am not sure that this use-case justifies a new option and more
> complications in the cod
On Wed, Aug 05, 2020 at 12:56:48AM +, Bossart, Nathan wrote:
> My main motive for adding the MAIN_RELATION_CLEANUP option is to allow
> table owners to easily vacuum only a relation's TOAST table. Roles do
> not have access to the pg_toast schema by default, so they might be
> restricted from
On Mon, 3 Aug 2020 at 15:47, Michael Paquier wrote:
>
> On Tue, Jul 14, 2020 at 05:34:01AM +, k.jami...@fujitsu.com wrote:
> > I've also confirmed those through regression + tap test in my own env
> > and they've passed. I'll look into deeply again if I find problems.
>
> + VACOPT_TOAST_CLEA
On 8/2/20, 11:47 PM, "Michael Paquier" wrote:
> + VACOPT_TOAST_CLEANUP = 1 << 6, /* process TOAST table, if any */
> + VACOPT_DISABLE_PAGE_SKIPPING = 1 << 7, /* don't skip any pages */
> + VACOPT_MAIN_REL_CLEANUP = 1 << 8/* process main relation */
> } VacuumOption;
>
> Do we actually
On Tue, Jul 14, 2020 at 05:34:01AM +, k.jami...@fujitsu.com wrote:
> I've also confirmed those through regression + tap test in my own env
> and they've passed. I'll look into deeply again if I find problems.
+ VACOPT_TOAST_CLEANUP = 1 << 6, /* process TOAST table, if any */
+ VACOPT_DISA
On Tuesday, July 14, 2020 3:01 AM (GMT+9), Bossart, Nathan wrote:
Hi Nathan,
>On 7/13/20, 11:02 AM, "Justin Pryzby" wrote:
>> Should bin/vacuumdb support this?
>
>Yes, it should. I've added it in v5 of the patch.
Thank you for the updated patch. I've joined as a reviewer.
I've also noticed tha
uot;
Date: Sun, 31 May 2020 22:13:39 +0000
Subject: [PATCH 1/3] Add MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP
options to VACUUM
Here is a rebased version of the patch.
Nathan
>From 27ccbb7af5d1e16da65c819b7fb93955395643d8 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Sun,
On Fri, Jan 24, 2020 at 09:31:26PM +, Bossart, Nathan wrote:
> On 1/21/20, 9:02 PM, "Michael Paquier" wrote:
>> On Tue, Jan 21, 2020 at 09:21:46PM +, Bossart, Nathan wrote:
>>> I've attached a patch for a couple of new options for VACUUM:
>>> MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CL
On 1/24/20, 1:32 PM, "Bossart, Nathan" wrote:
>>> I chose to disallow disabling both *_RELATION_CLEANUP options
>>> together, as this would essentially cause the VACUUM command to take
>>> no action.
>>
>> My first reaction is why? Agreed that it is a bit crazy to combine
>> both options, but if
On 1/21/20, 1:39 PM, "Vik Fearing" wrote:
> On 21/01/2020 22:21, Bossart, Nathan wrote:
>> I've attached a patch for a couple of new options for VACUUM:
>> MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP. The motive
>> behind these options is to allow table owners to easily vacuum only
>> th
On Tue, Jan 21, 2020 at 09:21:46PM +, Bossart, Nathan wrote:
> I've attached a patch for a couple of new options for VACUUM:
> MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP. The motive
> behind these options is to allow table owners to easily vacuum only
> the TOAST table or only the ma
On 21/01/2020 22:21, Bossart, Nathan wrote:
> I've attached a patch for a couple of new options for VACUUM:
> MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP. The motive
> behind these options is to allow table owners to easily vacuum only
> the TOAST table or only the main relation. This is
20 matches
Mail list logo
