Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oBS7Q-0005iJ-A4 for pgsql-admin@arkaria.postgresql.org; Wed, 13 Jul 2022 02:28:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oBS7O-0005rj-Pd for pgsql-admin@arkaria.postgresql.org; Wed, 13 Jul 2022 02:28:50 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oBS7O-0005ra-FU for pgsql-admin@lists.postgresql.org; Wed, 13 Jul 2022 02:28:50 +0000 Received: from mailout.easymail.ca ([64.68.200.34]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oBS7K-00084c-Ir for pgsql-admin@lists.postgresql.org; Wed, 13 Jul 2022 02:28:49 +0000 Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 66BAFE289B; Wed, 13 Jul 2022 02:28:44 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at emo08-pco.easydns.vpn Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo08-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3dWHEFrc708; Wed, 13 Jul 2022 02:28:44 +0000 (UTC) Received: from smtpclient.apple (unknown [4.28.96.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id BED91E27A5; Wed, 13 Jul 2022 02:28:43 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: [EXT] Improve "select count(*)" query - takes more than 30 mins for some large tables From: Scott Ribe In-Reply-To: Date: Tue, 12 Jul 2022 20:28:42 -0600 Cc: Laurenz Albe , "Pierson Patricia L (Contractor)" , "pgsql-admin@lists.postgresql.org" Content-Transfer-Encoding: quoted-printable Message-Id: <647F11EE-BBDA-46C1-8591-96B2C1DCE66C@elevated-dev.com> References: <1B1927BA-F7DE-40E8-8F67-BCC001CD4C6B@gmail.com> <1eb233ff-90f0-529b-f0cc-fa982f668a8f@gmail.com> <1221536526.20277.1657636277921@email.ionos.com> <1037158693.49441.1657650345834@email.ionos.com> <05fa08bf8b4e1023eb879bcab0f83d428e4f7a43.camel@cybertec.at> To: MichaelDBA X-Mailer: Apple Mail (2.3696.100.31) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On Jul 12, 2022, at 8:12 PM, MichaelDBA = wrote: >=20 > Oh really? Even if it did an INDEX ONLY SCAN, it would still be slower = because it still has to access the heap in a random I/O kinda way (like = I said-->"The heap always gets accessed for select counts") because = visibility info is only found in the HEAP not the index. This changed in 9.something. There is now a visibility map, which can, = for data that hasn't changed recently, greatly reduce the amount of = access required to the heap to determine visibility.=