Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Xxmv5-0001Xn-LO for pgsql-sql@arkaria.postgresql.org; Mon, 08 Dec 2014 01:15:23 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Xxmv4-0005oF-To for pgsql-sql@arkaria.postgresql.org; Mon, 08 Dec 2014 01:15:22 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Xxmv4-0005nt-3O for pgsql-sql@postgresql.org; Mon, 08 Dec 2014 01:15:22 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by makus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Xxmv1-0000ud-06 for pgsql-sql@postgresql.org; Mon, 08 Dec 2014 01:15:20 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 667192065C for ; Sun, 7 Dec 2014 20:15:18 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Sun, 07 Dec 2014 20:15:18 -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:subject :references:in-reply-to:content-type:content-transfer-encoding; s=mesmtp; bh=r40YU9DSo899Fb0K07fYjwW2Z6Y=; b=Sle9Hmq2Zqaiftp6Ne p1kbAmEhjlmpEOJzHRemKt+x9bfJ+kP7q4MRovcJWiHhNk3/NFsstH2AkcB4MxgG 9VcBpc8uOTsY2fzz4tPcPlOOutcGzJiFmpzVuOlRadEXL/aNIt6Im+o3AllXyKIQ pb833jxxth0rphZBbrEr+Wt7I= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:message-id:date:from :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=r40YU9DSo899Fb0K07fYjw W2Z6Y=; b=gZ8mdKNrSkSBHTotwz2gYkHY8Alw/pxp4qSAnFC9Kx5zMBbXYWTETl 8cnDLqcpzkx2mFK6OwOnGvq/3ISnpnN7lxFqvZeSfGEuR9OV348v7tUnblAifZYK NS9K+ZflI6yI+NaCQWNrPXP+WRktUutvt3KHD4KZiFRjJmIbzdlrE= X-Sasl-enc: uzbYt/q+Ekt+nx24l9IEjNSaFYuRxkzVo7w5Wa+cfufE 1418001318 Received: from [192.168.1.4] (unknown [174.21.228.172]) by mail.messagingengine.com (Postfix) with ESMTPA id D4CDC6801C5; Sun, 7 Dec 2014 20:15:17 -0500 (EST) Message-ID: <5484FBA5.8060902@aklaver.com> Date: Sun, 07 Dec 2014 17:15:17 -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: 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> <5484F69F.2030006@aklaver.com> <5484F963.40009@gmail.com> In-Reply-To: <5484F963.40009@gmail.com> 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/07/2014 05:05 PM, Tim Dudgeon wrote: > > On 07/12/2014 21:53, Adrian Klaver wrote: >> On 12/07/2014 04:43 PM, Tim Dudgeon wrote: >>> >>> On 07/12/2014 21:19, Adrian Klaver wrote: >>>> On 12/07/2014 02:59 PM, Tim Dudgeon wrote: >>>>> I was doing some performance profiling regarding querying against >>>>> jsonb >>>>> columns and found something I can't explain. >>>>> I created json version and standard column versions of some data, and >>>>> indexed the json 'fields' and the normal columns and executed >>>>> equivalent >>>>> queries against both. >>>>> I find that the json version is quite a bit (approx 3x) slower which I >>>>> can't explain as both should (and are according to plans are) working >>>>> against what I would expect are equivalent indexes. >>>>> >>>>> Can anyone explain this? >>>> >>>> The docs can: >>>> >>>> http://www.postgresql.org/docs/9.4/interactive/datatype-json.html#JSON-INDEXING >>>> >>>> >>> >>> If so them I'm missing it. >>> The index created is not a gin index. Its a standard btree index on the >>> data extracted from the json. So the indexes on the standard columns and >>> the ones on the 'fields' extracted from the json seem to be equivalent. >>> But perform differently. >> >> Down into the section there is this: >> >> "jsonb also supports btree and hash indexes. These are usually useful >> only if it's important to check equality of complete JSON documents. >> The btree ordering for jsonb datums is seldom of great interest, but >> for completeness it is: >> >> Object > Array > Boolean > Number > String > Null >> >> Object with n pairs > object with n - 1 pairs >> >> Array with n elements > array with n - 1 elements >> >> Objects with equal numbers of pairs are compared in the order: >> >> key-1, value-1, key-2 ... >> >> Note that object keys are compared in their storage order; in >> particular, since shorter keys are stored before longer keys, this can >> lead to results that might be unintuitive, such as: >> >> { "aa": 1, "c": 1} > {"b": 1, "d": 1} >> >> Similarly, arrays with equal numbers of elements are compared in the >> order: >> >> element-1, element-2 ... >> >> Primitive JSON values are compared using the same comparison rules as >> for the underlying PostgreSQL data type. Strings are compared using >> the default database collation. >> " >> >> As I understand it to get useful indexing into the jsonb >> datum(document) you need to use the GIN indexes. > > Yes, but if my understanding is correct I'm not indexing the JSON, I'm > indexing the PostgreSQL float type extracted from a field of the JSON, > and indexing using a btree index: > > create index idx_data_json_assay2_ic50 on json_test (((data ->> > 'assay2_ic50')::float)); > > The data ->> 'assay2_ic50' bit extracts the value from the JSON as text, Which is where I would say your slow down happens. I have not spent a lot of time jsonb as I have been waiting on the dust to settle from the recent big changes, so my empirical evidence is lacking. > the ::float bit casts to a float, and the index is built on the > resulting float type. > > And the index is being used, and is reasonably fast, just not as fast as > the equivalent index on the 'normal' float column. > > Tim >> >>> -- 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