Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZKrAO-0003bn-RD for pgsql-hackers@arkaria.postgresql.org; Thu, 30 Jul 2015 16:58:48 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZKrAO-0005rW-BQ for pgsql-hackers@arkaria.postgresql.org; Thu, 30 Jul 2015 16:58:48 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZKrAN-0005pQ-An for pgsql-hackers@postgresql.org; Thu, 30 Jul 2015 16:58:47 +0000 Received: from mail-wi0-x22a.google.com ([2a00:1450:400c:c05::22a]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1ZKrAJ-0003EA-W4 for pgsql-hackers@postgresql.org; Thu, 30 Jul 2015 16:58:46 +0000 Received: by wibxm9 with SMTP id xm9so218626wib.1 for ; Thu, 30 Jul 2015 09:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xUf080oo59n31XanMbfhGWIEQ5lubvlRSdg2o0aGFU0=; b=zadpyBR7UZgNw9pRMo/rFzc1REgcem4w7Zf8ojWzctoFtQpZcSim1HF7gEd/Iv4WuY RHm0KVUR/GSIDm929l3NtN0nFgGcIq9QOR3FVmr7cNEV/OYKCaSf7f6GdUGfhDmL1VRE WscYYzUnH5KCqV4gBXy1yk7n2LEOOnrYay2qLxgdb/xOl1ZvBPf7toQDZq/isQarXSru peAaRxX/9IHs3zzx0V7K9vzw+QVEV0Qd5wo68XJQbAecdqs7HcycDwNAL1S0AzsgD6WV xwRqQNrC4bzj0MGhqpPXvb8FU60QSaKg3ukgQ6mnWSjrFfB0VsMvtowV/FsYubucblBX 8+Zg== X-Received: by 10.180.23.69 with SMTP id k5mr8577081wif.3.1438275522517; Thu, 30 Jul 2015 09:58:42 -0700 (PDT) Received: from [192.168.1.105] (dsl-hkibrasgw1-58c38f-82.dhcp.inet.fi. [88.195.143.82]) by smtp.gmail.com with ESMTPSA id fs8sm2789836wjb.7.2015.07.30.09.58.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jul 2015 09:58:41 -0700 (PDT) Message-ID: <55BA57BF.7090901@iki.fi> Date: Thu, 30 Jul 2015 19:58:39 +0300 From: Heikki Linnakangas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Tomas Vondra , pgsql-hackers CC: Jeff Janes , Stephen Frost , Kyotaro HORIGUCHI Subject: Re: multivariate statistics / patch v7 References: <54C3FED3.1060600@2ndquadrant.com> <20150320.173307.249113775.horiguchi.kyotaro@lab.ntt.co.jp> <550C8E50.2010600@2ndquadrant.com> <20150324.143427.34552953.horiguchi.kyotaro@lab.ntt.co.jp> <5519E9B2.5080105@2ndquadrant.com> <20150428161310.GR30322@tamriel.snowman.net> <553FCE56.2000008@2ndquadrant.com> <554A73A6.2060603@2ndquadrant.com> <55638982.40904@2ndquadrant.com> <55B9DEA6.6030603@iki.fi> <55BA1ED6.4090302@2ndquadrant.com> In-Reply-To: <55BA1ED6.4090302@2ndquadrant.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.4 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 07/30/2015 03:55 PM, Tomas Vondra wrote: > On 07/30/2015 10:21 AM, Heikki Linnakangas wrote: >> I have some doubts about the clause reduction and functional >> dependencies part of this. It seems to treat functional dependency as >> a boolean property, but even with the classic zipcode and city case, >> it's not always an all or nothing thing. At least in some countries, >> there can be zipcodes that span multiple cities. So zipcode=X does >> not completely imply city=Y, although there is a strong correlation >> (if that's the right term). How strong does the correlation need to >> be for this patch to decide that zipcode implies city? I couldn't >> actually see a clear threshold stated anywhere. >> >> So rather than treating functional dependence as a boolean, I think >> it would make more sense to put a 0.0-1.0 number to it. That means >> that you can't do clause reduction like it's done in this patch, >> where you actually remove clauses from the query for cost esimation >> purposes. Instead, you need to calculate the selectivity for each >> clause independently, but instead of just multiplying the >> selectivities together, apply the "dependence factor" to it. >> >> Does that make sense? I haven't really looked at the MCV, histogram >> and "multi-statistics estimation" patches yet. Do those patches make >> the clause reduction patch obsolete? Should we forget about the >> clause reduction and functional dependency patch, and focus on those >> later patches instead? > > Perhaps. It's true that most real-world data sets are not 100% valid > with respect to functional dependencies - either because of natural > imperfections (multiple cities with the same ZIP code) or just noise in > the data (incorrect entries ...). And it's even mentioned in the code > comments somewhere, I guess. > > But there are two main reasons why I chose not to extend the functional > dependencies with the [0.0-1.0] value you propose. > > Firstly, functional dependencies were meant to be the simplest possible > implementation, illustrating how the "infrastructure" is supposed to > work (which is the main topic of the first patch). > > Secondly, all kinds of statistics are "simplifications" of the actual > data. So I think it's not incorrect to ignore the exceptions up to some > threshold. The problem with a threshold is that around that threshold, even a small change in the data set can drastically change the produced estimates. For example, imagine that we know from the stats that zip code implies city. But then someone adds a single row to the table with an odd zip code & city combination, which pushes the estimator over the threshold, and the columns are no longer considered dependent, and the estimates are now completely different. We should avoid steep cliffs like that. BTW, what is the threshold in the current patch? - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers