Re: Proposal "VACUUM SCHEMA" - Mailing list pgsql-hackers

From José Luis Tallón
Subject Re: Proposal "VACUUM SCHEMA"
Date
Msg-id 54983F06.9090800@adv-solutions.net
Whole thread Raw
In response to Re: Proposal "VACUUM SCHEMA"  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
Responses Re: Proposal "VACUUM SCHEMA"  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On 12/21/2014 10:30 PM, Fabrízio de Royes Mello wrote:
> [snip]

I do agree that "vacuum schema" might very well be useful (I'll probably 
use it myself from time to time, too).
ANALYZE SCHEMA (specially coupled with some transaction-wide "SET 
statistics_target" could be beneficial)

>
> > And why that, but not
> > say schema-wide ANALYZE, CLUSTER, TRUNCATE, ...
> >
>
> +1. I can write patches for each of this maintenance statement too.

Hmm... I think Tom might have been a bit rethorical (or even sarcastic 
with that), but I can definitely be wrong.

Do we really want to have some such operation potentially (and 
inadvertently) locking for *hours* at a time?

CLUSTER SCHEMA somename;
    ... where schema "somename" contains "myHugeTable"
    Given that the cluster command exclusively locks and rewrites the 
table, it might lock queries and overwhelm the I/O subsystem for quite a 
long time.


TRUNCATE SCHEMA whatever    sounds quite dangerous, too.



Just my .02€
    / J.L.





pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: btree_gin and ranges
Next
From: Andres Freund
Date:
Subject: Re: Proposal "VACUUM SCHEMA"