Re: A few new options for vacuumdb

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A few new options for vacuumdb
Date: 2019-01-09 18:42:40
Message-ID: 00A3F417-1E26-4717-9C2D-7AB4B91590FB@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/8/19, 10:34 PM, "Michael Paquier" <michael(at)paquier(dot)xyz> wrote:
> On Wed, Jan 09, 2019 at 10:33:00AM +0900, Masahiko Sawada wrote:
>> Since pg_(total)_relation_size() returns 0 for parent table the
>> specifying the parent table to vacuumdb with --min-relation-size
>> always does nothing. Maybe we will need to deal with this case when a
>> function returning whole partitoned table size is introduced.
>
> Good point. I am not sure if we want to go down to having a size
> function dedicated to partitions especially as this would just now be
> a wrapper around pg_partition_tree(), but the size argument with
> partitioned tables is something to think about. If we cannot sort out
> this part cleanly, perhaps we could just focus on the age-ing
> parameters and the other ones first? It seems to me that what is
> proposed on this thread has value, so we could shave things and keep
> the essential, and focus on what we are sure about for simplicity.

Sounds good. I'll leave out --min-relation-size for now.

Nathan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Karlsson 2019-01-09 18:49:37 Re: insensitive collations
Previous Message Andres Freund 2019-01-09 17:23:48 Re: Displaying and dumping of table access methods