Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ehCon-0002jU-7k for pgsql-admin@arkaria.postgresql.org; Thu, 01 Feb 2018 11:14:13 +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 1ehCol-0000Lb-3t for pgsql-admin@arkaria.postgresql.org; Thu, 01 Feb 2018 11:14:11 +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 1ehCok-0000LP-Sw for pgsql-admin@lists.postgresql.org; Thu, 01 Feb 2018 11:14:10 +0000 Received: from n3.nabble.com ([162.255.23.22]) by magus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ehCoh-0001bB-9b for pgsql-admin@postgresql.org; Thu, 01 Feb 2018 11:14:09 +0000 Received: from n3.nabble.com (localhost [127.0.0.1]) by n3.nabble.com (Postfix) with ESMTP id 160F0AED9CD8 for ; Thu, 1 Feb 2018 04:14:05 -0700 (MST) Date: Thu, 1 Feb 2018 04:14:05 -0700 (MST) From: pavan95 To: pgsql-admin@postgresql.org Message-ID: <1517483645048-0.post@n3.nabble.com> In-Reply-To: References: Subject: Re: Heap Only Update MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi Ali, Before changing the default value of Fillfactor, we should measure the size of Table Row. For knowing the row size is very important because if table row size is larger, we should not change the default value of Fillfactor. When we are doing performance optimization, this is very important to find the size of the Data page and Table row, otherwise unnecessary we are dealing with high fragmentation and executing VACUUM FULL or VACUUM again and again. The default Fillfactor is 100 and it is better, but not in all situations. *When your table has frequent updates, this is not a better solution because it requires more CPU and IO for different data page operations which actually degrade the performance*. The solution is to first measure the size of the tuple and if tuple size is not that much bigger, we can reduce the value of default Fillfactor. If your total row size is under 8kb, you can take decision to alter table storage parameters. You can use below script to measure the size of the tuple and if that size is not that big you can go ahead in decreasing the value of fill factor: WITH cteTableInfo AS ( SELECT COUNT(1) AS ct ,SUM(length(t::text)) AS TextLength ,'public.your_table_name'::regclass AS TableName FROM public.your_table_name AS t ) ,cteRowSize AS ( SELECT ARRAY [pg_relation_size(TableName) , pg_relation_size(TableName, 'vm') , pg_relation_size(TableName, 'fsm') , pg_table_size(TableName) , pg_indexes_size(TableName) , pg_total_relation_size(TableName) , TextLength ] AS val , ARRAY ['Total Relation Size' , 'Visibility Map' , 'Free Space Map' , 'Table Included Toast Size' , 'Indexes Size' , 'Total Toast and Indexes Size' , 'Live Row Byte Size' ] AS Name FROM cteTableInfo ) SELECT unnest(name) AS Description ,unnest(val) AS Bytes ,pg_size_pretty(unnest(val)) AS BytesPretty ,unnest(val) / ct AS bytes_per_row FROM cteTableInfo, cteRowSize UNION ALL SELECT '------------------------------', NULL, NULL, NULL UNION ALL SELECT 'TotalRows', ct, NULL, NULL FROM cteTableInfo UNION ALL SELECT 'LiveTuples', pg_stat_get_live_tuples(TableName), NULL, NULL FROM cteTableInfo UNION ALL SELECT 'DeadTuples', pg_stat_get_dead_tuples(TableName), NULL, NULL FROM cteTableInfo; Regards, Pavan -- Sent from: http://www.postgresql-archive.org/PostgreSQL-admin-f2076596.html