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 1mwWSD-0000oR-Ns for pgsql-hackers@arkaria.postgresql.org; Sun, 12 Dec 2021 21:32:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mwWSC-0004Sg-MQ for pgsql-hackers@arkaria.postgresql.org; Sun, 12 Dec 2021 21:32:20 +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 1mwWSC-0004SD-9w for pgsql-hackers@lists.postgresql.org; Sun, 12 Dec 2021 21:32:20 +0000 Received: from mail-io1-xd2b.google.com ([2607:f8b0:4864:20::d2b]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mwWS5-0007FS-EG for pgsql-hackers@postgresql.org; Sun, 12 Dec 2021 21:32:19 +0000 Received: by mail-io1-xd2b.google.com with SMTP id b187so16476519iof.11 for ; Sun, 12 Dec 2021 13:32:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=FpvYQZ3mpeApAlxuuhZKBf+BDs4Fm9BxRMj6cp4orlc=; b=FR9iX+yt2agVX8eeuqeMPcu6nKeNUwXYfyeCeYsXosETW+TPliLSzpRvUlWr/TUHui Lt+axJ5dSApT0e1TBX9hyYtHp+rrMAWnTk4bCvqIwnCZEn8p5B3/fRY2leowUZ2y+9/S LaLCAzYo8WxEh95egI8Rgcv0yOn2B9dROUcyH69Tza4dL1SiEz3+dYe8zF4vltoBPyST 2yS1M6aNyVNb4CGykJIkuJt2GaujLUXUqYu+JBoCS+987EdSXZMnSTJnP9bvvZ8C8wFG IJQUSgnly/+EfXwu1JWbrRfqVOpThHhe08ElvQ0K6sO2j9mRoGN0JCwy5oU8+R2kbPRM A6oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=FpvYQZ3mpeApAlxuuhZKBf+BDs4Fm9BxRMj6cp4orlc=; b=bXZ9QelevM6nBHJmpPFSUpAc/+RZMpcAxWFBmgzDQsKmYwmvjuc/cTcKCI4bCEVJCm Z5wSQCdAr49QL1srxQsL0W6e5NYTKJS9T2EFbQJl6mDADfR/IhKCtB6NRBCFZxSP/I2v zUe1oo8g5cdQzRObC/QNp4WPvf5MvwZ2IM1twSLhamzQwLYUnp20EZgZxXt9DUYbOlmC b7VmrnqgSksrTK4Bej+iiZbtfzf0KQFnvyYpieb5NOrmMfi8/3jT2HLHuXiiylOGUojg 3/rWpSjEtmnmzjwO7jlyJ2aowhxwBTaJ0TPFs8C0NxIecvjhl1HpcpIn00/f50XrXdU4 +Kew== X-Gm-Message-State: AOAM5307/WFJxOLrJ5Q82wroBbHh4BbrjiDeVdn9mMSWmW1nZW7PS5QQ AmBedk7x2e/dY0GosEDjIvIZJpEUTABy8g== X-Google-Smtp-Source: ABdhPJys4p5l5GRnPOwbcV+jq96gWevlCpmlPe46PdTU7kaaDPs51UVEKlZcWlhD6mV2XLmbXKLWHw== X-Received: by 2002:a6b:e60e:: with SMTP id g14mr29758085ioh.28.1639344731690; Sun, 12 Dec 2021 13:32:11 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id i8sm6398634ils.50.2021.12.12.13.32.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Dec 2021 13:32:11 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 5D5EA800B17; Sun, 12 Dec 2021 15:32:10 -0600 (CST) Date: Sun, 12 Dec 2021 15:32:10 -0600 From: Justin Pryzby To: Tomas Vondra Cc: Zhihong Yu , Jaime Casanova , pgsql-hackers@postgresql.org Subject: Re: extended stats on partitioned tables Message-ID: <20211212213210.GP17618@telsasoft.com> References: <20210925223152.GA7877@telsasoft.com> <20210926202550.GA831@telsasoft.com> <20211007202646.GA9522@ahch-to> <20211007224543.GH27491@telsasoft.com> <46f37069-55cb-db6a-a15a-e351a2606592@enterprisedb.com> <20211103231904.GP17618@telsasoft.com> <689accb1-76e8-5115-6ed0-336749cdca57@enterprisedb.com> <20211203052411.GU17618@telsasoft.com> <8052505e-2dd2-e8cb-26c9-cbb5dff7d750@enterprisedb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8052505e-2dd2-e8cb-26c9-cbb5dff7d750@enterprisedb.com> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sun, Dec 12, 2021 at 05:17:10AM +0100, Tomas Vondra wrote: > The one thing bugging me a bit is that the regression test checks only a > GROUP BY query. It'd be nice to add queries testing MCV/dependencies > too, but that seems tricky because most queries will use per-partitions > stats. You mean because the quals are pushed down to the scan node. Does that indicate a deficiency ? If extended stats are collected for a parent table, selectivity estimates based from the parent would be better; but instead we use uncorrected column estimates from the child tables. From what I see, we could come up with a way to avoid the pushdown, involving volatile functions/foreign tables/RLS/window functions/SRF/wholerow vars/etc. But would it be better if extended stats objects on partitioned tables were to collect stats for both parent AND CHILD ? I'm not sure. Maybe that's the wrong solution, but maybe we should still document that extended stats on (empty) parent tables are often themselves not used/useful for selectivity estimates, and the user should instead (or in addition) create stats on child tables. Or, maybe if there's no extended stats on the child tables, stats on the parent table should be consulted ? -- Justin