Message-ID: <548B5CF4.4030009@agliodbs.com>
Date: Fri, 12 Dec 2014 13:24:04 -0800
From: Josh Berkus <josh@agliodbs.com>
Organization: PostgreSQL Experts Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Tim Dudgeon <tdudgeon.ml@gmail.com>
CC: pgsql-sql@postgresql.org, pgsql-performance@postgresql.org
Subject: Re: Re: [SQL] 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>
 <5485C8BA.7040704@aklaver.com> <5485D584.8080105@aklaver.com>
 <27877.1418057764@sss.pgh.pa.us> <3936.1418071989@sss.pgh.pa.us>
 <548614C8.90203@aklaver.com> <54861A81.8030509@gmail.com>
 <WM!10a58876093961b15d913f3acfd3ae6e8f5f3f7b48bfbafc745c1350051f176f2eb1f0d024840ed24712614adf91b2b6!@asav-3.01.com>
In-Reply-To: 
 <WM!10a58876093961b15d913f3acfd3ae6e8f5f3f7b48bfbafc745c1350051f176f2eb1f0d024840ed24712614adf91b2b6!@asav-3.01.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On 12/08/2014 01:39 PM, Tim Dudgeon wrote:
> On 08/12/2014 18:14, Adrian Klaver wrote:
>> Recheck Cond: ((((data ->> 'assay1_ic50'::text))::double precision > 90::double precision) AND (((data ->> 'assay2_ic50'::text))::double precision < 10::double precision))
>> > 
>> > which means we have to pull the JSONB value out of the tuple, search
>> > it to find the 'assay1_ic50' key, convert the associated value to text
>> > (which is not exactly cheap because *the value is stored as a numeric*),
>> > then reparse that text string into a float8, after which we can use
>> > float8gt.  And then probably do an equivalent amount of work on the way
>> > to making the other comparison.
>> > 
>> > So this says nothing much about the lossy-bitmap code, and a lot about
>> > how the JSONB code isn't very well optimized yet.  In particular, the
>> > decision not to provide an operator that could extract a numeric field
>> > without conversion to text is looking pretty bad here.
> Yes, that bit seemed strange to me. As I understand the value is stored
> internally as numeric, but the only way to access it is as text and then
> cast back to numeric.
> I *think* this is the only way to do it presently?

Yeah, I believe the core problem is that Postgres currently doesn't have
any way to have variadic return times from a function which don't match
variadic input types.  Returning a value as an actual numeric from JSONB
would require returning a numeric from a function whose input type is
text or json.  So a known issue but one which would require a lot of
replumbing to fix.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance