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
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 |