Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4QMG-0006ew-EM for pgsql-admin@arkaria.postgresql.org; Tue, 17 Oct 2017 11:48:28 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1e4QMF-0008NX-Gm for pgsql-admin@arkaria.postgresql.org; Tue, 17 Oct 2017 11:48:27 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1e4QME-0008Mq-Qo for pgsql-admin@postgresql.org; Tue, 17 Oct 2017 11:48:26 +0000 Received: from intern.proventis.net ([217.111.101.34]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1e4QMB-0002fw-6y for pgsql-admin@postgresql.org; Tue, 17 Oct 2017 11:48:26 +0000 Received: from mail.proventis.net (unknown [192.168.22.239]) by intern.proventis.net (Postfix) with ESMTP id C419521A9E for ; Tue, 17 Oct 2017 13:48:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.proventis.net (Postfix) with ESMTP id BBD4C57EF16 for ; Tue, 17 Oct 2017 13:48:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.proventis.net Received: from mail.proventis.net ([127.0.0.1]) by localhost (mail.proventis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OA95XwZDp-r for ; Tue, 17 Oct 2017 13:48:21 +0200 (CEST) Received: from [192.168.22.130] (tmarkus.proventis.net [192.168.22.130]) by mail.proventis.net (Postfix) with ESMTP id 6DB7757EF2B for ; Tue, 17 Oct 2017 13:48:21 +0200 (CEST) Subject: Re: Autovacuum after bulk data insert(millions!) To: pgsql-admin@postgresql.org References: From: Thomas Markus Organization: proventis GmbH Message-ID: Date: Tue, 17 Oct 2017 13:48:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EA744B74876429599E2106E5" Content-Language: en-GB List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org This is a multi-part message in MIME format. --------------EA744B74876429599E2106E5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, Am 17.10.17 um 13:37 schrieb Günce Kaya: > Hello Fabrízio, > > Thank you for your advice but I'm not asking for only a specific table > and not looking for temporary solution. Previous post may not clear to > much and I'd explain again. > > So autovacuum process takes long time for that database. I don't know > how can I estimate timing for a vacuum after insert millions of bulk > data to a table. So there are many table inserting bulk data daily. > This solution not for only a table. I'm looking a solution for a > database. Data volume of this database is around 2GB so many > transactions in a day. > > This is only suggestion and I'm really curious because can not > estimate what do you think about that, what if disable autovacuum and > vacuum all tables in every month? > > Regards, > Gunce works same for a database, so it depends on your usecase * disable autovacuum for instance * run 'vacuumdb -a -z' manually/in cron Regards Thomas --------------EA744B74876429599E2106E5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

Am 17.10.17 um 13:37 schrieb Günce Kaya:
Hello Fabrízio,

Thank you for your advice but I'm not asking for only a specific table and not looking for temporary solution. Previous post may not clear to much and I'd explain again. 

So autovacuum process takes long time for that database. I don't know how can I estimate timing for a vacuum after insert millions of bulk data to a table. So there are many table inserting bulk data daily. This solution not for only a table. I'm looking a solution for a database. Data volume of this database is around 2GB so many transactions in a day. 

This is only suggestion and I'm really curious because can not estimate what do you think about that, what if disable autovacuum and vacuum all tables in every month?

Regards,
Gunce
works same for a database, so it depends on your usecase

* disable autovacuum for instance
* run 'vacuumdb -a -z' manually/in cron

Regards
Thomas

--------------EA744B74876429599E2106E5--