Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eSRbO-0005cb-Iw for pgsql-performance@arkaria.postgresql.org; Fri, 22 Dec 2017 17:59:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eSRbN-00023e-R7 for pgsql-performance@arkaria.postgresql.org; Fri, 22 Dec 2017 17:59:21 +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 1eSQSY-0004CA-S4 for pgsql-performance@lists.postgresql.org; Fri, 22 Dec 2017 16:46:10 +0000 Received: from forward101o.mail.yandex.net ([37.140.190.181]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eSQSV-00013u-Js for pgsql-performance@lists.postgresql.org; Fri, 22 Dec 2017 16:46:10 +0000 Received: from mxback11j.mail.yandex.net (mxback11j.mail.yandex.net [IPv6:2a02:6b8:0:1619::84]) by forward101o.mail.yandex.net (Yandex) with ESMTP id B183B1344BEA for ; Fri, 22 Dec 2017 19:46:04 +0300 (MSK) Received: from web46o.yandex.ru (web46o.yandex.ru [2a02:6b8:0:1a2d::5:226]) by mxback11j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id GC4iDEFuqC-k4Ne4da0; Fri, 22 Dec 2017 19:46:04 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1513961164; bh=VPzHsIfMB/Ahgk2HAT91BSsVrFgvxU0I1awC+g+/9OI=; h=From:To:Subject:Message-Id:Date; b=sHAkjipPwwYnyF54P9vAvUQ6b6guMRBI97htuPIM6lvpZsk9e0Zlxgd8Dc6n1g50r kxWn6egj0B/i6vM0VcAoNg5nqPZwQ4rMp+bBY3Joxlr8JajVO2uE4riRr0Uymzyi3C 69ThGpfvWBykRUiM+ZCAqN924rquT1ynRdMhCOvg= Authentication-Results: mxback11j.mail.yandex.net; dkim=pass header.i=@yandex.com Received: by web46o.yandex.ru with HTTP; Fri, 22 Dec 2017 19:46:03 +0300 From: Timokhin Maxim Envelope-From: ncx2@yandex.ru To: pgsql-performance@lists.postgresql.org Subject: Updating a large table MIME-Version: 1.0 Message-Id: <145941513961163@web46o.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Fri, 22 Dec 2017 19:46:03 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hello! We have a large table 11GB ( about 37 million records ) and we need to alter a table - add a new column with default values is false. Also 'NOT NULL' is required. So, first I've done: ALTER TABLE clusters ALTER COLUMN "is_paid"; after that: UPDATE clusters SET is_paid = DEFAULT where ctime <= now() - interval '720h' AND is_paid != FALSE; Everything went ok. Then I tried to run it again for an interval of 1 years. And I got that no one can't see - the was no available space on a disk. The reason was WAL-files ate everything. Master-server couldn't send some WAL-file to their replicas. Bandwidth wasn't enough. Well, I'm searching for a better idea to update the table. Solutions I found. 1. Separate my UPDATE by chunks. 2. Alter a table using a new temporary table, but it's not convenient for me because there is a lot of foreign keys and indexes. 3. Hot-update. This is the most interesting case for me. Speaking of HOT-update https://www.dbrnd.com/2016/03/postgresql-the-awesome-table-fillfactor-to-speedup-update-and-select-statement/ The article says: it might be useful for tables that change often and moreover It would be the best way to increase the speed of UPDATE. So, my questions are will it work for all tuples? It says that - no https://www.dbrnd.com/2016/03/postgresql-alter-table-to-change-fillfactor-value/, but I could not find a confirmation in official postresql's documentation. Why do I need to launch vacuum after updating? How should I reduce the better fillfactor? What will be with WAL-files it this case? Thank you! PostgreSQL 9.6 --  Timokhin 'maf' Maxim