2016-01-12 12:14 GMT+01:00 Michal Novotny <michal.novo...@trustport.com>:
> Hi Pavel, > thanks for the information. I've been doing more investigation of this > issue and there's autovacuum running on the table however it's > automatically starting even if there is "autovacuum = off" in the > postgresql.conf configuration file. > Real autovacuum is automatically cancelled. It looks like VACUUM started by cron, maybe? > > The test of rm 5T file was fast and not taking 24 hours already. I guess > the autovacuum is the issue. Is there any way how to disable it? If I > killed the process using 'kill -9' yesterday the process started again. > > Is there any way how to cancel this process and disallow PgSQL to run > autovacuum again and do the drop instead? > > Thanks, > Michal > > On 01/12/2016 12:01 PM, Pavel Stehule wrote: > > Hi > > > > 2016-01-12 11:57 GMT+01:00 Michal Novotny <michal.novo...@trustport.com > > <mailto:michal.novo...@trustport.com>>: > > > > Dear PostgreSQL Hackers, > > I've discovered an issue with dropping a large table (~5T). I was > > thinking drop table is fast operation however I found out my > assumption > > was wrong. > > > > Is there any way how to tune it to drop a large table in the matter > of > > seconds or minutes? Any configuration variable in the > postgresql.conf or > > any tune up options available? > > > > > > drop table should be fast. > > > > There can be two reasons why not: > > > > 1. locks - are you sure, so this statement didn't wait on some lock? > > > > 2. filesystem issue - can you check the speed of rm 5TB file on your IO? > > > > Regards > > > > Pavel > > > > > > > > > > > > > > PostgreSQL version used is PgSQL 9.4. > > > > Thanks a lot! > > Michal > > > > > > -- > > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org > > <mailto:pgsql-hackers@postgresql.org>) > > To make changes to your subscription: > > http://www.postgresql.org/mailpref/pgsql-hackers > > > > >
