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 1oAnl9-000674-Qi for pgsql-admin@arkaria.postgresql.org; Mon, 11 Jul 2022 07:23:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oAnl7-0001Se-E6 for pgsql-admin@arkaria.postgresql.org; Mon, 11 Jul 2022 07:23:09 +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 1oAnl7-0001SU-26 for pgsql-admin@lists.postgresql.org; Mon, 11 Jul 2022 07:23:09 +0000 Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oAnl3-0004Eu-UU for pgsql-admin@lists.postgresql.org; Mon, 11 Jul 2022 07:23:07 +0000 Received: by mail-wr1-x42b.google.com with SMTP id f2so5785390wrr.6 for ; Mon, 11 Jul 2022 00:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kOfNLxEF4PLFM5y+ZCiPNHKx5BtfQK6N3exKwDaCLOc=; b=TbVQbpsSjDndQi4qvtvngKeNh0z42rQIW2xsElDsVL1n8i4GikaSZJCYJlN2UXXqbk /3WPpgOVJZ9fDfZtusKvVkDGHTdZktHdH/IhUvthkfk/beHF1Z4aCyqNEavbdMm/M4up MvWJQSjNmsrHYrqfmXZ5WCR9RZZxXZ7yrTg7X7RQTXikeFTE3R2xuMz9juOhnr50NJnO 22Eml7JfzRGXCXDhKBu10O/vgKsDMO7JzTwkh0Ej7l14f9SLMQBLyy/qJ0EFR2xRFL4S 8/u+F8nRJmVB/Kg56hQj6dLLqSQX3aqLrmlS8Sx8GrfBlF/osimhH8Fiz0rOU3HdrjaI sRQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kOfNLxEF4PLFM5y+ZCiPNHKx5BtfQK6N3exKwDaCLOc=; b=cj+BWbD+UCzHV4T1+ZwgHozlybvusDu+JySrmQTuEosqvHh519N348D8YGOFHWq04d b8VfVFRDIIJ1ZYqjKLYBrqQgVWDh/hZtBQJf5XsBOaq4VKGRyJSoyxib8rbNSJCYh8hW xlNB3CcQSi7AXT+cKpVUGogazwFlkH3rg8BabKHrLAw2hKgX6cy4illc8t0SgApHlMkv ct+TQjYw0kRFgmtQb4ztI9reReARyZR3wiAISzc3iRX89fev721ZRnE1fANkZdy4L7fX U4lvXcVgFVG/aU8dep81pCuWNU0jlYNo2lMgQ1zTyN5rTFgWSapcd73iDSdUT4S7uqV3 iEQw== X-Gm-Message-State: AJIora8XQNC42PjreNvFNOUN32FcaLN5FcBvtW4fBvPmCQN4ucMU9BkI 3vg1uEzeuqZhskVUH6H1Ty4+GriQ1iIbdw== X-Google-Smtp-Source: AGRyM1uwtkJJ1xbTrPdxQUOwi/gieY90fZNaU9QkScqte4qhyyO6WbegZBl952Be/HHmwJgxBEZrQA== X-Received: by 2002:a5d:4806:0:b0:21d:66a2:5a52 with SMTP id l6-20020a5d4806000000b0021d66a25a52mr15360984wrq.632.1657524183192; Mon, 11 Jul 2022 00:23:03 -0700 (PDT) Received: from smtpclient.apple (ppp-94-66-221-5.home.otenet.gr. [94.66.221.5]) by smtp.gmail.com with ESMTPSA id b18-20020a5d45d2000000b0021d7ff34df7sm5985492wrs.117.2022.07.11.00.23.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jul 2022 00:23:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: Improve "select count(*)" query - takes more than 30 mins for some large tables From: Florents Tselai In-Reply-To: Date: Mon, 11 Jul 2022 10:23:01 +0300 Cc: Pgsql-admin Content-Transfer-Encoding: quoted-printable Message-Id: <1B1927BA-F7DE-40E8-8F67-BCC001CD4C6B@gmail.com> References: To: Raj kumar 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 11 Jul 2022, at 10:16 AM, Raj kumar = wrote: >=20 > Hi, >=20 > How can I improve "select count(*)" for larger tables? I'm doing a db = migration and need to validate the data count. > "select count(*) " queries are taking more than 30 minutes for some = tables which is more than the downtime we have. > Will work_mem increase help? or how can i speed up this row count? Personally, whenever I=E2=80=99ve had slow count(*) or count (distinct = id), eventually=20 I=E2=80=99ve resorted to Unix tools. psql =E2=80=9Cselect id from my_table" | sort -u | wc -l =20 The convenience/performance tradeoff depends heavily on your schema. After all unix streams don=E2=80=99t know much about your integrity = requirements. >=20 > Thanks, > Raj