From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Geoff Winkless <gwinkless(at)gmail(dot)com> |
Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: jsonb problematic operators |
Date: | 2016-12-16 15:21:13 |
Message-ID: | 32168.1481901673@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Geoff Winkless <gwinkless(at)gmail(dot)com> writes:
> To look at this from the other angle, is there a reason why the jsonb
> indexes don't work with the jsonb_ functions but only with the
> operators? Is this something that could be changed easily?
Yes. No. However, if you're desperate, you could make SQL wrapper
functions:
regression=# create function my_jsonb_exists(jsonb, text) returns bool
regression-# language sql as 'select $1 ? $2';
CREATE FUNCTION
regression=# create table foo(f1 jsonb);
CREATE TABLE
regression=# create index on foo using gin(f1);
CREATE INDEX
regression=# explain select * from foo where my_jsonb_exists(f1, 'bar');
QUERY PLAN
-------------------------------------------------------------------------
Bitmap Heap Scan on foo (cost=8.01..12.02 rows=1 width=32)
Recheck Cond: (f1 ? 'bar'::text)
-> Bitmap Index Scan on foo_f1_idx (cost=0.00..8.01 rows=1 width=0)
Index Cond: (f1 ? 'bar'::text)
(4 rows)
This works because a simple SQL function like this will get inlined before
any interesting planning decisions are made.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-12-16 15:33:45 | Re: Hang in pldebugger after git commit : 98a64d0 |
Previous Message | Peter Eisentraut | 2016-12-16 15:17:00 | Re: background sessions |