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 1mvsZL-0000J9-7U for pgsql-admin@arkaria.postgresql.org; Sat, 11 Dec 2021 02:57:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mvsZJ-0002nl-8J for pgsql-admin@arkaria.postgresql.org; Sat, 11 Dec 2021 02:57:01 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mvsZI-0002nb-UB for pgsql-admin@lists.postgresql.org; Sat, 11 Dec 2021 02:57:00 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mvsZG-0002IY-3R for pgsql-admin@lists.postgresql.org; Sat, 11 Dec 2021 02:57:00 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 1BB2urQJ013149; Fri, 10 Dec 2021 21:56:53 -0500 From: Tom Lane To: Wells Oliver cc: Ron , pgsql-admin@lists.postgresql.org Subject: Re: Very slow 101-feeling design/query.. In-reply-to: References: <144f1205-22cc-b6ef-b0f9-21c7d271397a@gmail.com> Comments: In-reply-to Wells Oliver message dated "Fri, 10 Dec 2021 15:27:58 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13147.1639191413.1@sss.pgh.pa.us> Date: Fri, 10 Dec 2021 21:56:53 -0500 Message-ID: <13148.1639191413@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Wells Oliver writes: > PG 13.4. Can't quite run the EXPLAIN ANALYZE since it takes so long, but > EXPLAIN SELECT DISTINCT game_id FROM vw_joints shows (s = joints, p = plays) I doubt you're going to get a query plan that's significantly better than what you show here. But those tables are pretty large, so I wonder whether you have cranked up work_mem. One potential issue is that the planner thinks there are only about 1829 distinct game_id values: > HashAggregate (cost=63810150.11..63810168.40 rows=1829 width=4) > Group Key: p.game_id Is that about the right size of result for this? regards, tom lane