Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eIjiH-0005q9-On for pgsql-hackers@arkaria.postgresql.org; Sat, 25 Nov 2017 23:18:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eIjiH-0006Z2-BA for pgsql-hackers@arkaria.postgresql.org; Sat, 25 Nov 2017 23:18:21 +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_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eIjiG-0006Ys-Vq for pgsql-hackers@lists.postgresql.org; Sat, 25 Nov 2017 23:18:21 +0000 Received: from mail-wm0-x233.google.com ([2a00:1450:400c:c09::233]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eIjiD-0002F3-A1 for pgsql-hackers@postgresql.org; Sat, 25 Nov 2017 23:18:20 +0000 Received: by mail-wm0-x233.google.com with SMTP id 9so27857592wme.4 for ; Sat, 25 Nov 2017 15:18:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=43aAGxZlYk++2SrSf56rFh1YVIz3zXzB/V+YqMwx0nQ=; b=SR2kWtG+6g3ihUXAJJPMN4s/IR3iB3Hhv+L/kZrGyOqtswN8+mwALMKFe+80kHLHSk 1pH8uIWRHMgNJ87BOxH4/CNEqptLBb1bHizPxsROnrpt4py7OT9AaXBtk0S/mgzwV9ZU 73Cfl6qyxeqt3Q0nLwAHB5RECfvBB6Gq4tpzcewOPTE1eq3KJt3FhK/2Xbzw03lfbdSK oqI/hFuLXBJRBxoH1pkLAwH1Xz+iLqGDSEkSg588PmdDQa3zcbJnqqauBmaAXg6wgkbj ABLxCY4dktM0ySZRTo50SqpuyCdT0RyvdQArP7CFXDXfYhPVXmCsr/b7fI2KTyeoFSs0 +rQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=43aAGxZlYk++2SrSf56rFh1YVIz3zXzB/V+YqMwx0nQ=; b=DIegpuL1a3W4e5+J59y+pdR/vpVMMeXVQCOedQwiJDOAeatcB3/EDzPz5KTNsrocp8 iC+A9mgJyfVT52gAbmCe1LFPezquus1s39oF9/eXmB0nEwLyraxsyodzWW4mldVgIlt1 7f7jevZMwD4eE1DoR44l1fm511m4MywTs1/9WKOtpC9JBYGcUi1jyipaGGjWqAT6VMTi xBlOP29Xl1h5TcHxia9LmKdGUnIhlYbmBhliybTXkPIwgzBhY4PxHhYSui7wJ1deyriL gcvtdKYkEqsLnb+F1tk8fVQIgaSCw6FgQMUgfEsPnaB3TAIfl4BGpiN3JeQ9+R0fGcEo ujgQ== X-Gm-Message-State: AJaThX63PpCdpqN5xLpYY+fupb0LqOjoN6P37ctkT++n/gJlteL8rtg+ aUpDixhM0Mu0iTUYx46QhvqAMPrH98vxoO7hGxc/40ieyqz33183n1Vrm68JOuPwIDAODN1Bw5F fhUwukekr3Erwd6Qb+wld/TrdBFdI92eOAS65Pu79FrBStOkd95oa6aIksHdb2o3EEiKC+Oizfs vavnh3dwBq X-Google-Smtp-Source: AGs4zMb6pm+cBsjn2pYRR4FN4XC6/eRHyZJGc0AtvpSRJmyyWTAPBaa14HmesFN6M9W3xdXUx3mb9w== X-Received: by 10.28.18.1 with SMTP id 1mr15230762wms.88.1511651894671; Sat, 25 Nov 2017 15:18:14 -0800 (PST) Received: from [10.137.2.19] (ip-78-102-97-226.net.upcbroadband.cz. [78.102.97.226]) by smtp.gmail.com with ESMTPSA id u33sm15740219wrf.42.2017.11.25.15.18.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Nov 2017 15:18:13 -0800 (PST) Subject: Re: [HACKERS] PATCH: multivariate histograms and MCV lists To: Mark Dilger Cc: Adrien Nayrat , Pg Hackers References: <31ee8686-6d62-7f10-4129-7580ec74a710@dalibo.com> <340ffd44-2d67-d39d-e54f-5a97a842cd3a@2ndquadrant.com> <67EAB5B3-F9FB-4753-8102-4D77DCFFFCD4@gmail.com> <5F255F0E-3F31-4753-87D7-3C4768A2B967@gmail.com> From: Tomas Vondra Message-ID: <4fc51dca-c165-167b-6468-a668552a4a93@2ndquadrant.com> Date: Sun, 26 Nov 2017 00:18:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <5F255F0E-3F31-4753-87D7-3C4768A2B967@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, On 11/25/2017 09:23 PM, Mark Dilger wrote: > >> On Nov 18, 2017, at 12:28 PM, Tomas Vondra wrote: >> >> Hi, >> >> Attached is an updated version of the patch, adopting the psql describe >> changes introduced by 471d55859c11b. >> >> regards >> >> -- >> Tomas Vondra http://www.2ndQuadrant.com >> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >> <0001-multivariate-MCV-lists.patch.gz><0002-multivariate-histograms.patch.gz> > > Hello Tomas, > > After applying both your patches, I get a warning: > > histogram.c:1284:10: warning: taking the absolute value of unsigned type 'uint32' (aka 'unsigned int') has no effect [-Wabsolute-value] > delta = fabs(data->numrows); > ^ > histogram.c:1284:10: note: remove the call to 'fabs' since unsigned values cannot be negative > delta = fabs(data->numrows); > ^~~~ > 1 warning generated. > Hmm, yeah. The fabs() call is unnecessary, and probably a remnant from some previous version where the field was not uint32. I wonder why you're getting the warning and I don't, though. What compiler are you using? > > Looking closer at this section, there is some odd integer vs. floating point arithmetic happening > that is not necessarily wrong, but might be needlessly inefficient: > > delta = fabs(data->numrows); > split_value = values[0].value; > > for (i = 1; i < data->numrows; i++) > { > if (values[i].value != values[i - 1].value) > { > /* are we closer to splitting the bucket in half? */ > if (fabs(i - data->numrows / 2.0) < delta) > { > /* let's assume we'll use this value for the split */ > split_value = values[i].value; > delta = fabs(i - data->numrows / 2.0); > nrows = i; > } > } > } > > I'm not sure the compiler will be able to optimize out the recomputation of data->numrows / 2.0 > each time through the loop, since the compiler might not be able to prove to itself that data->numrows > does not get changed. Perhaps you should compute it just once prior to entering the outer loop, > store it in a variable of integer type, round 'delta' off and store in an integer, and do integer comparisons > within the loop? Just a thought.... > Yeah, that's probably right. But I wonder if the loop is needed at all, or whether we should start at i=(data->numrows/2.0) instead, and walk to the closest change of value in both directions. That would probably save more CPU than computing numrows/2.0 only once. The other issue in that block of code seems to be that we compare the values using simple inequality. That probably works for passbyval data types, but we should use proper comparator (e.g. compare_datums_simple). regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services