Re: Proposal "VACUUM SCHEMA"
От | Stephen Frost |
---|---|
Тема | Re: Proposal "VACUUM SCHEMA" |
Дата | |
Msg-id | 20141222170542.GF3062@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: Proposal "VACUUM SCHEMA" (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: Proposal "VACUUM SCHEMA"
|
Список | pgsql-hackers |
* Alvaro Herrera (alvherre@2ndquadrant.com) wrote: > 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. I could see it happening in environments which use schemas when doing partitioning. eg: data_2014 contains all of the data_201401-201412 monthly (or perhaps weekly) tables. > Overall, this whole line of development seems like bloating the parse > tables for little gain. Still, I see this point also. I do think it'd be really great if we could figure out a way to segregate these kinds of DDL / maintenance commands from the normal select/insert/update/delete SQL parsing, such that we could add more options, etc, to those longer running and less frequent commands without impacting parse time for the high-volume commands. I'm less concerned about the memory impact, except to the extent that it impacts throughput and performance. Thanks, Stephen
В списке pgsql-hackers по дате отправления: