Re: Proposal "VACUUM SCHEMA"

Поиск
Список
Период
Сортировка
От José Luis Tallón
Тема Re: Proposal "VACUUM SCHEMA"
Дата
Msg-id 54983F06.9090800@adv-solutions.net
обсуждение исходный текст
Ответ на Re: Proposal "VACUUM SCHEMA"  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
Ответы Re: Proposal "VACUUM SCHEMA"  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: btree_gin and ranges
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Proposal "VACUUM SCHEMA"