Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s5bec-006eRc-JC for pgsql-general@arkaria.postgresql.org; Sat, 11 May 2024 01:36:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1s5bea-002aon-TL for pgsql-general@arkaria.postgresql.org; Sat, 11 May 2024 01:36:01 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s5bea-002ani-GQ for pgsql-general@lists.postgresql.org; Sat, 11 May 2024 01:36:00 +0000 Received: from mail-lj1-x22a.google.com ([2a00:1450:4864:20::22a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s5beX-000RJg-2C for pgsql-general@lists.postgresql.org; Sat, 11 May 2024 01:36:00 +0000 Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2e0a0cc5e83so42112461fa.1 for ; Fri, 10 May 2024 18:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715391356; x=1715996156; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hC/fz7e3b5SAJJ4O4+GQLiKlRForQo7+l/126utxm1M=; b=dm11fvYqZe2VlfGvMuoWtFCwOLer2llW4jh4xS6tYLNIPGunQRcpb5sFZXTqvQmP7b O0QMj4neNoBselh23LF2EkYRARvR8AihUER36Uvu3Nh+sc0osA5aaWBUUd4expHwHkPp UgA3XZSHFl0lmQF2pY0S9HhwxvGkAKuI/WYc6cJGsnf1vWM4YK497R0YXUM01ftwlxcJ mGTFzXioQuCmCGHkS1oV6OwIIecKsdyFr4/E9dNr36V2Z9yvrUsO6PdnEHxS8+TqHk9F 6vJKiiGjc62i6qa3iEQNTBSySJNBPilu8VUytzdVB/T88r79cMa9bDgboeMuIOj/cpmg X69A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715391356; x=1715996156; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hC/fz7e3b5SAJJ4O4+GQLiKlRForQo7+l/126utxm1M=; b=eXyUzDjZg7EQdYROYqwt0BJfvMIl8NxbsQbRN25uslWUCMkYifSeQOtDTjlHdA0dCU N3/TXlI3iV459KnK07ff/hr+HTRptRk0BDhT/4sAs4TEmewaDCQlVOc12EPFceGshs1x PKuY0gHZsQN+smvwAfwoXmlff7iYfastupvXjNTjW+v0dgL8ynteTsZn/uBKLBoD6UJD ak3KapRYblzdmqdnfaaXEDYvyuU4UqbeGxzJvs8+DF4llAHT7rx3cv4yrlKLe5joYCGo dziCejgI2bTAgQRN6G4rwmZDtL4Vc/s8EW1uN06ajyxG3+JTAul3l3G64AoPoLYPCML9 ut6Q== X-Forwarded-Encrypted: i=1; AJvYcCXIcit0GaCguvO3/ZnjsVRyeyH2gXdM+uiouw2Dt63C2jh1Mw8NAhrhLHexwyA2BJdJNoDpUKwUXfOJf8m6e1irxCUBOA5uLwyLEZnz8tkWbQeO X-Gm-Message-State: AOJu0Yz9o6F4IR96Ev3/oCFv+JFHsnNm4InU349cpj/e7ICE2R2r7ZXt O9wfhhw9CmRIn/30ArFpSFmlEkzatg5rDOyGScibsilVVNQOTlX0V8/pklQIe/AjBKWOSSVkC73 GJjMxjLwKecJ8CfHuwGOd5v8J0Uo= X-Google-Smtp-Source: AGHT+IFx5RDrQyOenDRsijuiTZdsC73aE3bcMOoL4K8l5XeI/HgRMIs+rh7t1LnjKy6l/mtTCNgwZ8svTuIc8QMcIKs= X-Received: by 2002:a2e:9604:0:b0:2df:55a3:43af with SMTP id 38308e7fff4ca-2e5204ccd01mr23474031fa.41.1715391355893; Fri, 10 May 2024 18:35:55 -0700 (PDT) MIME-Version: 1.0 References: <7886a68f-b466-2131-1747-f69f0fb71a37@gmx.net> <69077f15-4125-2d63-733f-21ce6eac4f01@gmx.net> <559b0e40-63e6-fa9a-6b03-d1eba10f30f8@gmx.net> <1629463.1715372568@sss.pgh.pa.us> <6a2f3906-3d7a-6924-7403-8f77d57a18e4@gmx.net> In-Reply-To: <6a2f3906-3d7a-6924-7403-8f77d57a18e4@gmx.net> From: David Rowley Date: Sat, 11 May 2024 13:35:44 +1200 Message-ID: Subject: Re: SELECT DISTINCT chooses parallel seqscan instead of indexscan on huge table with 1000 partitions To: Dimitrios Apostolou Cc: Tom Lane , pgsql-general@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, 11 May 2024 at 13:11, Dimitrios Apostolou wrote: > Indeed that's an awful estimate, the table has more than 1M of unique > values in that column. Looking into pg_stat_user_tables, I can't see the > partitions having been vacuum'd or analyzed at all. I think they should > have been auto-analyzed, since they get a ton of INSERTs > (no deletes/updates though) and I have the default autovacuum settings. > Could it be that autovacuum starts, but never > finishes? I can't find something in the logs. It's not the partitions getting analyzed you need to worry about for an ndistinct estimate on the partitioned table. It's auto-analyze or ANALYZE on the partitioned table itself that you should care about. If you look at [1], it says "Tuples changed in partitions and inheritance children do not trigger analyze on the parent table." > In any case, even after the planner decides to execute the terrible plan > with the parallel seqscans, why doesn't it finish right when it finds 10 > distinct values? It will. It's just that Sorting requires fetching everything from its subnode. David [1] https://www.postgresql.org/docs/16/routine-vacuuming.html#VACUUM-FOR-STATISTICS