From: | Christoph Berg <cb(at)df7cb(dot)de> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | José Luis Tallón <jltallon(at)adv-solutions(dot)net>, fabriziomello(at)gmail(dot)com, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal "VACUUM SCHEMA" |
Date: | 2014-12-22 16:58:49 |
Message-ID: | 20141222165836.GA11110@msg.df7cb.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Re: Alvaro Herrera 2014-12-22 <20141222165157(dot)GD1768(at)alvh(dot)no-ip(dot)org>
> Multi-table CLUSTER uses multiple transactions, so this should not be an
> issue. That said, I don't think there's much point in CLUSTER SCHEMA,
> much less TRUNCATE SCHEMA. Do you normally organize your schemas so
> that there are some that contain only tables that need to be truncated
> together? That would be a strange use case.
Having a schema that's only used for importing data in batch jobs
doesn't sound too unreasonable. It could then be cleaned in a simple
"TRUNCATE SCHEMA import_area" command.
> Overall, this whole line of development seems like bloating the parse
> tables for little gain.
Reading the thread, my impression was that most people opposed the
idea because there's ways to script "vacuum schema", or because of
"people shouldn't be invoking manual vacuums anyway". I think the
patch tries to solve a practical problem, and does have its merits.
Christoph
--
cb(at)df7cb(dot)de | http://www.df7cb.de/
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2014-12-22 17:05:42 | Re: Proposal "VACUUM SCHEMA" |
Previous Message | Alvaro Herrera | 2014-12-22 16:51:57 | Re: Proposal "VACUUM SCHEMA" |