Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Yb79V-0005tr-5V for pgsql-performance@arkaria.postgresql.org; Thu, 26 Mar 2015 12:44:49 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Yb79U-00056k-JK for pgsql-performance@arkaria.postgresql.org; Thu, 26 Mar 2015 12:44:48 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Yb79T-00054Z-3X for pgsql-performance@postgresql.org; Thu, 26 Mar 2015 12:44:47 +0000 Received: from mail-wi0-f169.google.com ([209.85.212.169]) by magus.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Yb79O-0000L8-I6 for pgsql-performance@postgresql.org; Thu, 26 Mar 2015 12:44:45 +0000 Received: by wiaa2 with SMTP id a2so20752498wia.0 for ; Thu, 26 Mar 2015 05:44:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3nxi+ZIB5F4kdQIQpoe/+UkAm83V5mgL+wlVMqCsLO8=; b=C/wWhHobtZfZNtnSfIUE4km3j9K+lv2zy0yHjiiSQTQ7Sm9bOSwk6FHNuhtrMOlPPB ivPaqBMPRGDAC5YUrkaytU8KNPxyNrvD3jtX/QpI5+5WFTkn/GT+520639BWb/gG/nJ7 vmO+LvhQ2ktt1xJaFaXeApGNF1pZ/UZ/lrqYHeHyA5kqdTKCo7cHESFb77XeMxi3JZ0m 1VT51Yswfko7bW5xuITgNJszsBCVaw3vK5tgWo5Wur+eXP5WOonUW2rjwdZuEMTJWe6P 0yn7rUCmGIXuT2pICgQcKw3YW0uUEOBFt71RFkUGpLLUMQ3G0QevIDbYsR67M0yezjZI tHow== X-Gm-Message-State: ALoCoQmDi2/GVQDcXSES4+XfXU0D240tFx8s3wogTiqTHccBLL6cQ9z0SfozGbcFDI+PtvE66FGXSNB10TONMkbnuD9SIl73uI91lsQovFvoDAsXA8za13UEW4cHA42zAptKV9wYPvR8iAXS26eofHS30VgoJyZ+yTRCXYD4Z+iD5H3x1wCSeh+1E0zxdSW161MB6B81dIRP X-Received: by 10.194.75.193 with SMTP id e1mr27211959wjw.126.1427373880460; Thu, 26 Mar 2015 05:44:40 -0700 (PDT) Received: from [192.168.1.163] (ip-78-45-139-138.net.upcbroadband.cz. [78.45.139.138]) by mx.google.com with ESMTPSA id cz7sm1199314wib.15.2015.03.26.05.44.39 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 05:44:39 -0700 (PDT) Message-ID: <5513FF23.8090603@2ndquadrant.com> Date: Thu, 26 Mar 2015 13:44:19 +0100 From: Tomas Vondra Organization: 2ndQuadrant User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Index only scan sometimes switches to sequential scan for small amount of rows References: <5512ADD2.7080402@2ndquadrant.com> <7439.1427304380@sss.pgh.pa.us> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On 26.3.2015 08:48, Jeff Janes wrote: > > OK, this is starting to look like a long-standing bug to me. > > If it only sees 3 distinct values, and all three are present at least > twice, it throws all of them into the MCV list. But if one of those 3 > were present just once, then it tests them to see if they qualify. > The test for inclusion is that it has to be present more than once, > and that it must be "over-represented" by 25%. > > Lets say it sampled 30000 rows and found 29,900 of one value, 99 of > another, and 1 of a third. > > But that turns into the second one needing to be present 12,500 times. > The average value is present 10,000 times (30,000 samples with 3 > distinct values) and 25 more than that is 12,500. So it excluded. > > It seems to me that a more reasonable criteria is that it must be > over-represented 25% compared to the average of all the remaining values > not yet accepted into the MCV list. I.e. all the greater ones should be > subtracted out before computing the over-representation threshold. That might work IMO, but maybe we should increase the coefficient a bit (say, from 1.25 to 2), not to produce needlessly long MCV lists. > It is also grossly inconsistent with the other behavior. If they are > "29900; 98; 2" then all three go into the MCV. Isn't the mincount still 12500? How could all three get into the MCV? -- Tomas Vondra http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance