Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fC2Kk-00069O-KH for pgsql-www@arkaria.postgresql.org; Fri, 27 Apr 2018 12:18:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fC2Kj-0007Ys-HW for pgsql-www@arkaria.postgresql.org; Fri, 27 Apr 2018 12:18:37 +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.89) (envelope-from ) id 1fC0TW-0006bx-JH for pgsql-www@lists.postgresql.org; Fri, 27 Apr 2018 10:19:34 +0000 Received: from mail-wm0-x241.google.com ([2a00:1450:400c:c09::241]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fC0TT-0005Vu-Ec for pgsql-www@postgresql.org; Fri, 27 Apr 2018 10:19:33 +0000 Received: by mail-wm0-x241.google.com with SMTP id m70so1425968wma.2 for ; Fri, 27 Apr 2018 03:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:subject:from:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=8wcbS3OZQe5FhFcKhTUvECganGFJF/biIo6l9UmRDFk=; b=AEyMmIcm1dbru5jmrfic+9B+PWFDxg2NzhP3SlQDZWAkuTSrat8TcznPvppeLupZSo IkghuMSyajJAAudhxRH74FEEJQYE7Qa1iEz0LDc8QkrNmp3N2PNsDsByT49nvvyndGLp WspMCLmWPJ8DlWvS/g+bdfuMrFcSTMzFkIaH8C1v8+kd97sXO8NQ65Hy274qvSa5CSzU jY8sIkA9in1YxNwgmj3EF5sdAi+FGiFSOE8mIPr7/llSPnQCd1qb3WDAhXHPIZMVAGrV anvO05XHnDMWU6AyMDXEVlYbdiMIahlKWABffzXFNTZKhDNbjUJ/H+GA0+Io+lnGo3LY wdPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:subject:from:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=8wcbS3OZQe5FhFcKhTUvECganGFJF/biIo6l9UmRDFk=; b=h9VhtRjfrcxPtLsl1I2BAHo64BMDl+oZZWV+mAemks3Q2wC7kOxWoOvDUwLyalG5XX a+MALsuiiR8DxDK5Iu1n35zIFtCuCZiDZxGk1Pss6nJ2KN9V/M51X2j1Z48ujTQktj/D P/xaE9fW7wG4ut5//3YvlXrhHf/MGZqoWgjnow9h1qF/3TMMQire2MwGmT+jT+OFgtH+ Zaysn+oHfS5Wm0SnojmsHxL2I9syCQNL1j1AuhxrFAQT8QjnnaLxAi46ragf31MdPtAp 8AYxu5DOO4WkQBzXkbe9Oifg+CcyW7T0xLK1Uo1Fq+xho1ly15Mu25cHmG8HwdniiN2c ILnA== X-Gm-Message-State: ALQs6tBcVl8hcBCjSJEyWrNdjzAJ25jyeAYt5ZROpDhTac2Hg5CpDa5W 2muj9i+DqCVQwiB1/L6he3mixrnT X-Google-Smtp-Source: AB8JxZp0nHUl1iLu2cG0FOT4EOxoTi+KnQte91vctviSlSPD4qkSRxkGfi895Le3h1Nn8DCqBFIEcA== X-Received: by 10.28.208.70 with SMTP id h67mr946830wmg.80.1524824369000; Fri, 27 Apr 2018 03:19:29 -0700 (PDT) Received: from [134.246.102.170] ([134.246.102.170]) by smtp.gmail.com with ESMTPSA id r14-v6sm2087470wra.41.2018.04.27.03.19.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Apr 2018 03:19:28 -0700 (PDT) To: pgsql-www@postgresql.org Subject: Wiki editor request From: "David M. Kaplan" Message-ID: <9b106c7b-4d27-4211-401e-26c6a7b4d4fb@gmail.com> Date: Fri, 27 Apr 2018 12:19:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, I noticed something that I do not think is correct on the PostgreSQL wiki and would like to edit it, but don't have the privileges. Could you either edit it for me or give me the privileges? My account is based on my gmail dmkaplan2000@gmail.com The think that I noticed that seems incorrect to me has to do with the histogram aggregate code snippet here https://wiki.postgresql.org/wiki/Aggregate_Histogram. I believed that the author misinterpreted the fact that width_bucket uses nbuckets+1 buckets (actually nbuckets+2 buckets) as not appropriate and tries to correct for that, but I don't think current code does what it is supposed to. width_bucket returns values between 0 and nbuckets+1 where a value of 0 means val=MAX. These first and last buckets are actually useful information that should be kept, and the existing code puts into a bucket -1 all values less than the MIN and bucket=nbuckets all values that exceed the MAX, which is incorrect. I believe the correct code should be: CREATE OR REPLACE FUNCTION hist_sfunc (state INTEGER[], val DOUBLE PRECISION,        MIN DOUBLE PRECISION, MAX DOUBLE PRECISION, nbuckets INTEGER) RETURNS INTEGER[] AS $$ DECLARE   bucket INTEGER;   i INTEGER; BEGIN   -- This will put values in buckets with a 0 bucket for =MAX   bucket := width_bucket(val, MIN, MAX, nbuckets);   -- Init the array with the correct number of 0's so the caller doesn't see NULLs   IF state[0] IS NULL THEN     FOR i IN SELECT * FROM generate_series(0, nbuckets + 1) LOOP       state[i] := 0;     END LOOP;   END IF;   state[bucket] = state[bucket] + 1;   RETURN state; END; $$ LANGUAGE plpgsql IMMUTABLE; -- Tell Postgres how to use the new function DROP AGGREGATE IF EXISTS histogram (DOUBLE PRECISION, DOUBLE PRECISION, DOUBLE PRECISION, INTEGER); CREATE AGGREGATE histogram (DOUBLE PRECISION, DOUBLE PRECISION, DOUBLE PRECISION, INTEGER) (        SFUNC = hist_sfunc,        STYPE = INTEGER[] ); To confirm that this is correct, please compare the original histogram aggregate with my version using the following query: WITH a AS ( SELECT generate_series(-2,5,0.5) AS i ) SELECT array_agg(i) AS values,        histogram(i,0,3,3) AS counts, (histogram(i,0,3,3))[1:3] AS counts_in_limits FROM a; Thanks, David