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 1jGtty-0007eS-GP for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Mar 2020 00:28:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jGttx-0001Mk-BT for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Mar 2020 00:28:09 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1jGttw-0001Mb-Tf for pgsql-hackers@lists.postgresql.org; Wed, 25 Mar 2020 00:28:09 +0000 Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jGttt-00005x-Sl for pgsql-hackers@lists.postgresql.org; Wed, 25 Mar 2020 00:28:08 +0000 Received: by mail-wr1-x42b.google.com with SMTP id 31so893330wrs.3 for ; Tue, 24 Mar 2020 17:28:05 -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=S0fZ40UzrriocQCUU9v2V0NY+C0mgFoWst6cmguZtZ8=; b=CsLBcSbG3yEcDAfHkqCICBj8JTDQ3z53rmZUdej2l8tksGk9kihfwmHw6PAHMh6JY0 qND0RtT8SKnP8d17PdD2YR4d6byvvFPHjPjSFLyt+LPWYwHQURjZuz37s105+5ZdAyC2 nQjDFdwqe+cXhN8KPfl/r41Rd9sYYcD5hN3X6sN9a3eiZ3mT73cwOVNQMG30hThkgC92 iTRNkOa14CGzl8SwC9Oy6qXmTfTm0dC5J4jc+99mA69HQVB0RufIVuKdzDur3QCJut8/ xp1DoMRqeLBqQ7V1NG+Sm6p1GcASUg/Q7VFAOydx97qbtLSADh/HOFq8A0Q74rhTeYBJ GwIA== 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=S0fZ40UzrriocQCUU9v2V0NY+C0mgFoWst6cmguZtZ8=; b=nu+kPWZE0QgOL3J9qd0u/8ExNUQ4DF43z665wEafT9+8WhnWJNFh0vTEezoc9JuCdz 0yj9cnXVg7xAv9pIUb0O+IAxnSGvgNbNxmHJOV2SmFDx3VEKsikWaOxClf+Uv+uvL0O7 uWWpNlxKe8pi9Dl6RZumO3Ds1Eu0Oqrk8abSBaurtPrIxjCnUDO2TWb2iDAk32/jsp5G OiqnkIuaO18PWQCLP0ASUg1Zw40SyL40BM/25pvps8IGZFQ4CjOVes1ne4FMMxug4WT0 WTQvB7vDwyZG5cd7M+0qmUyBjHe1AFKYOgw+1m61ASrRAwNiu0xIW3AFQBYmd5jVTcSj n4OQ== X-Gm-Message-State: ANhLgQ0dTvaEP4n9afYBhH2PxA5uP70q40rGq2Jn+2le7dH4AUdsfNa2 jcSNEHX38NXoG9H8Gz7JTHlNJw== X-Google-Smtp-Source: ADFU+vuMoHfNt6zSWlckXAPNXBIyh0DuUpvjZJc6bLSNj8gFyvGJshKQ2iWSQltjvzpoyxCfnTz/og== X-Received: by 2002:a5d:420e:: with SMTP id n14mr382495wrq.10.1585096084190; Tue, 24 Mar 2020 17:28:04 -0700 (PDT) Received: from localhost (ip-86-49-253-92.net.upcbroadband.cz. [86.49.253.92]) by smtp.gmail.com with ESMTPSA id e6sm30047490wrn.29.2020.03.24.17.28.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Mar 2020 17:28:03 -0700 (PDT) Date: Wed, 25 Mar 2020 01:28:01 +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: <20200325002801.i45f34l45rqmik4v@development> References: <20200313160944.aqrbkyf7tkasoxfk@development> <20200314152159.5webesf6pfluatqj@development> <20200314184535.4jgkxcyg5yprvsra@development> <20200317153706.z6pdtijr25iyr424@development> <20200317170517.hutarq3sioyny3wa@development> <20200318002946.6dvblukm3cfmgir2@development> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, Mar 19, 2020 at 07:53:39PM +0000, Dean Rasheed wrote: >On Wed, 18 Mar 2020 at 00:29, Tomas Vondra wrote: >> >> OK, I took a look. I think from the correctness POV the patch is OK, but >> I think the dependencies_clauselist_selectivity() function now got a bit >> too complex. I've been able to parse it now, but I'm sure I'll have >> trouble in the future :-( >> >> Can we refactor / split it somehow and move bits of the logic to smaller >> functions, or something like that? >> > >Yeah, it has gotten a bit long. It's somewhat tricky splitting it up, >because of the number of shared variables used throughout the >function, but here's an updated patch splitting it into what seemed >like the 2 most logical pieces. The first piece (still in >dependencies_clauselist_selectivity()) works out what dependencies >can/should be applied, and the second piece in a new function does the >actual work of applying the list of functional dependencies to the >clause list. > >I think that has made it easier to follow, and it has also reduced the >complexity of the final "no applicable stats" branch. > Seems OK to me. I'd perhaps name deps_clauselist_selectivity differently, it's a bit too similar to dependencies_clauselist_selectivity. Perhaps something like clauselist_apply_dependencies? But that's a minor detail. >> Another thing I'd like to suggest is keeping the "old" formula, and >> instead of just replacing it with >> >> P(a,b) = f * Min(P(a), P(b)) + (1-f) * P(a) * P(b) >> >> but explaining how the old formula may produce nonsensical selectivity, >> and how the new formula addresses that issue. >> > >I think this is purely a comment issue? I've added some more extensive >comments attempting to justify the formulae. > Yes, it was purely a comment issue. Seems fine now. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services