From: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | "'Sridhar N Bamandlapally *EXTERN*'" <sridhar(dot)bn1(at)gmail(dot)com> |
Cc: | PG-General Mailing List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: [ADMIN] How to drop stats on table |
Date: | 2015-11-23 08:46:54 |
Message-ID: | A737B7A37273E048B164557ADEF4A58B50FE9A38@ntex2010i.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-general |
Sridhar N Bamandlapally wrote:
> the actual issue is, when
>
> 1. temp table <say tmp1>is created with rows
> 2. stats/analyze on table (tmp1)
> 3. table dropped (tmp1)
>
> but in stats related catalog tables a blot is created
What is a blot in this context? Are you talking about "bloat"?
> In this scenario, thousands of temp tables created per day, blots are increasing and stats related
> tables are growing to 10's of GB
>
> however, we schedule vacuum on catalog tables to control size
>
> the worry is, catalog tables also undergo MVCC concept
>
> I think when table is dropped, should have option to remove or reuse related blot-space on catalog
> tables
It must be "bloat" you're talking about.
Do you have "autovacuum = on"?
If yes, it should take care of the problem if there are only thousands
of temporary tables per day.
What do you get for
SELECT last_autovacuum, last_autoanalyze
FROM pg_stat_sys_tables
WHERE schemaname = 'pg_catalog' AND relname = 'pg_statistic';
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Campbell, Lance | 2015-11-23 14:37:08 | pg_restore new parameter request |
Previous Message | Masaru Sugawara | 2015-11-22 14:48:19 | Re: 【楽天ブックス】お届けできなかった商品に関するお詫び |
From | Date | Subject | |
---|---|---|---|
Next Message | Albe Laurenz | 2015-11-23 08:59:39 | Re: What could cause CREATE TEMP... "could not read block" error? |
Previous Message | 657985552@qq.com | 2015-11-23 06:20:58 | Re: ??: postgres cpu 100% need help |