Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Xy0Zu-0007JW-L8 for pgsql-sql@arkaria.postgresql.org; Mon, 08 Dec 2014 15:50:26 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Xy0Zu-0001U3-19 for pgsql-sql@arkaria.postgresql.org; Mon, 08 Dec 2014 15:50:26 +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 1Xy0Zt-0001Tl-Br for pgsql-sql@postgresql.org; Mon, 08 Dec 2014 15:50:25 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by magus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Xy0Zp-000120-BO for pgsql-sql@postgresql.org; Mon, 08 Dec 2014 15:50:24 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id D623120F5F for ; Mon, 8 Dec 2014 10:50:19 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 08 Dec 2014 10:50:19 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=aklaver.com; h= x-sasl-enc:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; s=mesmtp; bh=efu6sGT+LunCGfADjdeKOkRe/tY=; b=FWSFGGVUYcRXCc/6K9 HxYq0pPD/YzzVzJP2gJjyENlm/fDUEZgMHwwcXpS5ZSLbS/2ogLOb8RGp1/zX7/J HEopfUANmHLJp5umaHKY2Gff+yF6pwaZnWpkvwVZbV6zZrc50CgrM7lNrcX+1MoN MhCL8gj+Krz55tcnCuooyDa0g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=efu6sGT+LunCGfADjdeKOk Re/tY=; b=g3GbJhW/t/OwjoxTJ458QfSUC87FOnUka7XrYEDfJ/Xsgjl0L8jwqB Qt8orD4V4fBwA8bVAvsr732PkXJaGs7E+1W1v3Tb+EijaX4CStAcqZb5wXOUxwYQ hTmyHOKSIPci25uB3MXX48o3HCtIyMH+4yjPVxhzEhA+P5psB+sPY= X-Sasl-enc: 0xa0r8OfVPKh+xMtnuil6II9UctDXVwwi7WdRbSbg6h2 1418053819 Received: from [192.168.1.4] (unknown [174.21.85.155]) by mail.messagingengine.com (Postfix) with ESMTPA id 4ABC9C00284; Mon, 8 Dec 2014 10:50:19 -0500 (EST) Message-ID: <5485C8BA.7040704@aklaver.com> Date: Mon, 08 Dec 2014 07:50:18 -0800 From: Adrian Klaver User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Tom Lane CC: Tim Dudgeon , pgsql-sql@postgresql.org Subject: Re: querying with index on jsonb slower than standard column. Why? References: <5484DBDA.6090405@gmail.com> <5484EEA7.1030403@aklaver.com> <5484F437.2080402@gmail.com> <16147.1418002090@sss.pgh.pa.us> <5485C449.4020204@aklaver.com> <26002.1418053572@sss.pgh.pa.us> In-Reply-To: <26002.1418053572@sss.pgh.pa.us> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-sql Precedence: bulk Sender: pgsql-sql-owner@postgresql.org On 12/08/2014 07:46 AM, Tom Lane wrote: > Adrian Klaver writes: >> On 12/07/2014 05:28 PM, Tom Lane wrote: >>> I don't see any particular difference ... > >> Running the above on my machine I do see the slow down the OP reports. I >> ran it several times and it stayed around 3.5x. > > Interesting. A couple of points that might be worth checking: > > * I tried this on a 64-bit build, whereas you were evidently using 32-bit. My laptop is 64-bit, so when I get a chance I will setup the test there and run it to see what happens. > > * The EXPLAIN ANALYZE output shows that my bitmaps didn't go lossy, > whereas yours did. This is likely because I had cranked up work_mem to > make the index builds go faster. > > It's not apparent to me why either of those things would have an effect > like this, but *something* weird is happening here. > > (Thinks for a bit...) A possible theory, seeing that the majority of the > blocks are lossy in your runs, is that the reduction to lossy form is > making worse choices about which blocks to make lossy in one case than in > the other. I don't remember exactly how those decisions are made. > > Another thing that seems odd about your printout is the discrepancy > in planning time ... the two cases have just about the same planning > time for me, but not for you. > > regards, tom lane > > -- Adrian Klaver adrian.klaver@aklaver.com -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql