On Fri, Nov 20, 2015 at 11:24 PM, Sridhar N Bamandlapally
wrote:
> the actual issue is, when
>
> 1. temp table is created with rows
> 2. stats/analyze on table (tmp1)
> 3. table dropped (tmp1)
>
> but in stats related catalog tables a blot is created
>
> In this scenario, thousands of temp tables
of cause it's mvcc and can be vacuumed by autovacuum or manually.
but 10's of GB sounds wrong for me, not sure how many tables you have, but
it's just too much.
anyway you can vacuum tables more aggressively on system level, or manually
vacuum the stats table.
see my test with 1000 tables 10K rows
Alex Luya writes:
> My postgresql 9.4 is installed in centos 6.7,and I have followed this:
> http://www.cyberciti.biz/faq/postgresql-remote-access-or-connection/
> 1,cd /usr/pgsql-9.4/share/
> 2,cp postgresql.conf.sample postgresql.conf
> 3,sudo vi postgresql.conf and add two lines,and save it:
My postgresql 9.4 is installed in centos 6.7,and I have followed this:
http://www.cyberciti.biz/faq/postgresql-remote-access-or-connection/
1,cd /usr/pgsql-9.4/share/
2,cp postgresql.conf.sample postgresql.conf
3,sudo vi postgresql.conf and add two lines,and save it:
> *listen_addresses = "
On 11/20/2015 11:24 PM, Sridhar N Bamandlapally wrote:
the actual issue is, when
1. temp table 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 scenario, thousands of temp tables crea
