Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jEb2t-0005gm-Ll for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Mar 2020 15:55:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jEb2s-00045B-Ck for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Mar 2020 15:55:50 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1jEb2s-000454-0d for pgsql-hackers@lists.postgresql.org; Wed, 18 Mar 2020 15:55:50 +0000 Received: from mail-wr1-x444.google.com ([2a00:1450:4864:20::444]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jEb2p-0007yJ-IO for pgsql-hackers@lists.postgresql.org; Wed, 18 Mar 2020 15:55:48 +0000 Received: by mail-wr1-x444.google.com with SMTP id h4so10471957wru.2 for ; Wed, 18 Mar 2020 08:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=FHP33sCjWELNyoQg6+yJxmijYh0+Jzoo8MSonxBZ5lA=; b=V5qUEK1paS+yYi9LMBEsH0VTbNCS1GCVsuHPSsmn1XaeXgO+r4tATGD+0gEWNYe9kI XXzSClMJdGkoxoYsXFMNSxQ++8YT+JOqJhjYmjKcNQrij1KK2cMGQyeQc00zY2SjPFDo oe5t/iVkZQeayFhuEK2CKyjDYga8uce25ugdKFpWX8PB2o1kaZgWeNsO9q0lilekhm6P 2fgyKGw6fhc2VEq6VE/+osWun9qVRzLfJEohN1vYsEM5JMoLJeYEHB5aDgM6/dFYI1i6 cRruuNO5i3TNSQfGCdG0fJqDUtQER6h60OqpdjPWhaa+tBjqTi9ekbZKg+FQ0hJpSncB OP1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=FHP33sCjWELNyoQg6+yJxmijYh0+Jzoo8MSonxBZ5lA=; b=MQThF1pvllfWqhS+Hsc5+HkSXOR255cyIWKBVBb0SCNFOMMIiJeMr0uCOwjmp7Gyzf 7hvJDTmSwCxvI9zYKiwwTnnGkJXUrb7xdsFKxS5r4KQft+2EnFSu4kEW7BUrG4EkrjHU Nk58BoG0KyUewAI4kJwzmCKJYQj6j3iqJAb44rQk3dVZ2GnUp84h5+8r1KtnA+weIgL7 KL+hceeJ6qtRUutWcNI8lJDOYbM/J/+mv0cmvz7GiXQWBkAfvWBTkIqGtfVF+hwOgToi EwlvY7CZqtVMPIFpm2gUSy0eSSCcf3716nJ777hdAifOV6qIcltSn3pV4W87Jm237rtE KESg== X-Gm-Message-State: ANhLgQ0mDmbYYBHNN5YBR8ZPPNzeTVLfayTRl5qxUBusGsBB7EovdqFS AsW/1CFywYAe4aMMZCXEii06lA== X-Google-Smtp-Source: ADFU+vtuGUJuTQeFFQUiVeHD2qQnItFO3FgQZCHfXrCKvheA3r9JhqRp8C0HKnGL3uXxPOwLmEjyTA== X-Received: by 2002:a5d:6910:: with SMTP id t16mr6092946wru.209.1584546945976; Wed, 18 Mar 2020 08:55:45 -0700 (PDT) Received: from localhost (ip-86-49-253-92.net.upcbroadband.cz. [86.49.253.92]) by smtp.gmail.com with ESMTPSA id g8sm4473276wmk.26.2020.03.18.08.55.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Mar 2020 08:55:45 -0700 (PDT) Date: Wed, 18 Mar 2020 16:55:43 +0100 From: Tomas Vondra To: Dean Rasheed Cc: Pierre Ducroquet , PostgreSQL Hackers Subject: Re: PATCH: add support for IN and @> in functional-dependency statistics use Message-ID: <20200318155543.n72l4lj5kkcklbik@development> References: <3937607.jCdSCb7NGl@pierred-pdoc> <20200202184134.swoqkqlqorqolrqv@development> <20200312173047.stp55sxoj4sipn7q@development> <20200313160944.aqrbkyf7tkasoxfk@development> <20200314152159.5webesf6pfluatqj@development> <20200314184535.4jgkxcyg5yprvsra@development> <20200317153706.z6pdtijr25iyr424@development> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20200317153706.z6pdtijr25iyr424@development> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Tue, Mar 17, 2020 at 04:37:06PM +0100, Tomas Vondra wrote: >On Tue, Mar 17, 2020 at 12:42:52PM +0000, Dean Rasheed wrote: >>On Sat, 14 Mar 2020 at 18:45, Tomas Vondra wrote: >>> >>>I realized there's one more thing that probably needs discussing. >>>Essentially, these two clause types are the same: >>> >>> a IN (1, 2, 3) >>> >>> (a = 1 OR a = 2 OR a = 3) >>> >>>but with 8f321bd1 we only recognize the first one as compatible with >>>functional dependencies. It was always the case that we estimated those >>>two clauses a bit differently, but the differences were usually small. >>>But now that we recognize IN as compatible with dependencies, the >>>difference may be much larger, which bugs me a bit ... >>> >>>So I wonder if we should recognize the special form of an OR clause, >>>with all Vars referencing to the same attribute etc. and treat this as >>>supported by functional dependencies - the attached patch does that. >>>MCV lists there's already no difference because OR clauses are >>>supported. >>> >> >>Makes sense, and the patch looks straightforward enough. >> >>>The question is whether we want to do this, and whether we should also >>>teach the per-column estimates to recognize this special case of IN >>>clause. >> >>I'm not convinced about that second part though. I'd say that >>recognising the OR clause for functional dependencies is sufficient to >>prevent the large differences in estimates relative to the equivalent >>IN clauses. The small differences between the way that OR and IN >>clauses are handled have always been there, and I think that changing >>that is out of scope for this work. >> > >Not sure. I think the inconsistency between plan and extended stats may >be a bit surprising, but I agree that issue may be negligible. > OK, I've pushed the change recognizing the special case of OR clauses as supported by functional dependencies. I've left the estimation of the clause itself as it's, we can address that in the future if needed. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services