Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Pavel Stehule
Hi 2016-01-12 11:57 GMT+01:00 Michal Novotny : > 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

Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Marko Tiikkaja
On 12/01/16 12:17, Pavel Stehule wrote: 2016-01-12 12:14 GMT+01:00 Michal Novotny : 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

Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Michal Novotny
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. The test of rm 5T file was fast and not taking 24

Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Pavel Stehule
2016-01-12 12:14 GMT+01:00 Michal Novotny : > 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 >

Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Michal Novotny
Hi Andres, thanks a lot. I've managed to run DROP TABLE and then cancel process using pg_cancel_backend(autovacuum_pid) and it passed and dropped the 5T table. Thanks a lot! Michal On 01/12/2016 12:37 PM, Andres Freund wrote: > Hi, > > On 2016-01-12 12:17:01 +0100, Michal Novotny wrote: >>

Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Michal Novotny
Hi Andres, thanks a lot for your reply. Unfortunately I've found out most it didn't really start DROP TABLE yet and it's locked on autovacuum running for the table and even if I kill the process it's autostarting again and again. Is there any way how to do the DROP TABLE and bypass/disable

Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Pavel Stehule
2016-01-12 12:22 GMT+01:00 Marko Tiikkaja : > On 12/01/16 12:17, Pavel Stehule wrote: > >> 2016-01-12 12:14 GMT+01:00 Michal Novotny : >> >> Hi Pavel, >>> thanks for the information. I've been doing more investigation of this >>> issue and there's

Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Andres Freund
On 2016-01-12 12:17:09 +0100, Pavel Stehule wrote: > 2016-01-12 12:14 GMT+01:00 Michal Novotny : > > > 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 > >

Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Andres Freund
Hi, On 2016-01-12 12:17:01 +0100, Michal Novotny wrote: > thanks a lot for your reply. Unfortunately I've found out most it didn't > really start DROP TABLE yet and it's locked on autovacuum running for > the table and even if I kill the process it's autostarting again and again. Start the DROP

Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Michal Novotny
Hi Andres, On 01/12/2016 12:37 PM, Andres Freund wrote: > Hi, > > On 2016-01-12 12:17:01 +0100, Michal Novotny wrote: >> thanks a lot for your reply. Unfortunately I've found out most it didn't >> really start DROP TABLE yet and it's locked on autovacuum running for >> the table and even if I

Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Andres Freund
Hi Michal, This isn't really a question for -hackers, the list for postgres development. -general or -performance would have been more appropriate. On 2016-01-12 11:57:05 +0100, Michal Novotny wrote: > I've discovered an issue with dropping a large table (~5T). I was > thinking drop table is

Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Michal Novotny
On 01/12/2016 12:20 PM, Andres Freund wrote: > On 2016-01-12 12:17:09 +0100, Pavel Stehule wrote: >> 2016-01-12 12:14 GMT+01:00 Michal Novotny : >> >>> Hi Pavel, >>> thanks for the information. I've been doing more investigation of this >>> issue and there's

[HACKERS] Question about DROP TABLE

2016-01-12 Thread Michal Novotny
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