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 1oBFNh-0001S5-GT for pgsql-admin@arkaria.postgresql.org; Tue, 12 Jul 2022 12:52:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oBFMh-0005sj-Sc for pgsql-admin@arkaria.postgresql.org; Tue, 12 Jul 2022 12:51:47 +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 1oBFMh-0005ny-GH for pgsql-admin@lists.postgresql.org; Tue, 12 Jul 2022 12:51:47 +0000 Received: from mail-qv1-xf33.google.com ([2607:f8b0:4864:20::f33]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oBFMe-0001eC-K9 for pgsql-admin@lists.postgresql.org; Tue, 12 Jul 2022 12:51:46 +0000 Received: by mail-qv1-xf33.google.com with SMTP id l15so2453904qvo.11 for ; Tue, 12 Jul 2022 05:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to; bh=HeDMy/NkPbquqWSoPvpvyr3otihPWfGBuY3HoJjJJeU=; b=MEPH04AJH4fu5AuOPXdSlBNvBizbx8I6wySwtY2zVDTtrfwRvq4wKYyZ9mgF8rUjmd jtFsafjpqVlQ+dKeylJVvMlaMRMwRVI0HfTdOUcJOSYm20vUfUThqL66FC+CmmokCji3 H1wdYukopbik7t301jZYj1ATBnpUokuc9EszAlIYc7lFtoGAnWJlwmLTRDMgWWQaLLyr +5A8Gb/Q2Xuh0qFTVsj57l13bHVTfx1EMZvQerg3bo/vzi/VkNLXqw+ejLPjupMxBT83 X/aODl/JWungh0WBX512GbPapjivPKvRx6eazcUIbw+mil/ot9ifJPKZZ2ix9IQPmJDh uK2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to; bh=HeDMy/NkPbquqWSoPvpvyr3otihPWfGBuY3HoJjJJeU=; b=Hg64phczBwPbU55rupkIMfVYU4uSLhivcUFvJGuFa90upE2WfuNxYradPwL8NuBipu /PCY+L2phGCbYUDm7I9vy9I3r4FCnwos2kM/5GzM/OG5NSGydS8kOJ6fexId2XxVukl6 cXZvpnqSw89oJdGH39+yr2rEqPP+5yDtEJQJc3uYcgHFlU5cpP52NIwA2dLgOEB94UKM aRNYAa9+NG2mOfIZ4kQ2zpibQ8kw5XnODjHe1qdDtA3bE1y9UY0/5VHnScMboSlPWuyl CuPkvNJupJcXfJPN7qdGw8wmF4x6guPdB/Fa8QHk3eaQyisGgRzy9ireAPf+HORrSTgT a3uw== X-Gm-Message-State: AJIora/8h6g5yDO1mZ1FV4f1N3ia+DVMnj5Egyv25G4mCfFex9gz0On5 U6vK3AqMf7k6ZVcrbdk/ZJU+8B/+T7GY3Q== X-Google-Smtp-Source: AGRyM1s6GQrlJ1p5qPUgvEdAPsmHwydap5C5VP4EqtXdHk+jWniSrXNlrsqfFRITZZniWheIBqFrRw== X-Received: by 2002:a0c:cb10:0:b0:473:8572:4560 with SMTP id o16-20020a0ccb10000000b0047385724560mr2035890qvk.128.1657630303371; Tue, 12 Jul 2022 05:51:43 -0700 (PDT) Received: from [192.168.2.100] (pool-72-79-19-93.nwrknj.east.verizon.net. [72.79.19.93]) by smtp.gmail.com with ESMTPSA id l10-20020a05620a28ca00b006b59f02224asm2259766qkp.60.2022.07.12.05.51.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Jul 2022 05:51:42 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------0xV6QrN3ZAjZxPVhiWkA1x52" Message-ID: <1eb233ff-90f0-529b-f0cc-fa982f668a8f@gmail.com> Date: Tue, 12 Jul 2022 08:51:42 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: Improve "select count(*)" query - takes more than 30 mins for some large tables Content-Language: en-US To: pgsql-admin@lists.postgresql.org References: <1B1927BA-F7DE-40E8-8F67-BCC001CD4C6B@gmail.com> From: Mladen Gogala In-Reply-To: <1B1927BA-F7DE-40E8-8F67-BCC001CD4C6B@gmail.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------0xV6QrN3ZAjZxPVhiWkA1x52 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 7/11/22 03:23, Florents Tselai wrote: > psql “select id from my_table" | sort -u | wc -l That will be a lot slower than just "select count(*) from my_table".  You are delivering data to the user program (psql) and then shipping them to pipe and then processing the output with "wc". Depending on the version, PostgreSQL has very reliable parallelism and can do counting rather quickly. The speed of "select count(*) from my_table" depends on the speed of I/O. Since the table is big, it cannot be cached in the file system cache, so all that you have at your disposal is the raw disk speed. For the smaller machines, NVME is the king. For larger rigs, you should consider something like Pure, XTremIO or NetApp SolidFire. People frequently expect database to do miracles with under par hardware. -- Mladen Gogala Database Consultant Tel: (347) 321-1217 https://dbwhisperer.wordpress.com --------------0xV6QrN3ZAjZxPVhiWkA1x52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 7/11/22 03:23, Florents Tselai wrote:
psql “select id from my_table" | sort -u | wc -l   

That will be a lot slower than just "select count(*) from my_table".  You are delivering data to the user program (psql) and then shipping them to pipe and then processing the output with "wc". Depending on the version, PostgreSQL has very reliable parallelism and can do counting rather quickly. The speed of "select count(*) from my_table" depends on the speed of I/O. Since the table is big, it cannot be cached in the file system cache, so all that you have at your disposal is the raw disk speed. For the smaller machines, NVME is the king. For larger rigs, you should consider something like Pure, XTremIO or NetApp SolidFire. People frequently expect database to do miracles with under par hardware.

-- 
Mladen Gogala
Database Consultant
Tel: (347) 321-1217
https://dbwhisperer.wordpress.com
--------------0xV6QrN3ZAjZxPVhiWkA1x52--