From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: jsonb existence queries are misimplemented by jsonb_ops |
Date: | 2014-05-07 21:28:53 |
Message-ID: | CAM3SWZQfkNYa=OO13gBwcHtXi1Mh5D45RPwKcc8KjZY2wa_jWQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, May 7, 2014 at 1:39 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> The indexscan is incorrectly returning rows where the queried key exists
> but isn't at top-level.
>
> We could fix this either by giving up on no-recheck for existence queries,
> or by changing the way that non-top-level keys get indexed. However
> I suspect the latter would break containment queries, or at least make
> their lives a lot more difficult.
Thanks for looking into this.
I don't know that it would make life all that much harder for
containment. jsonb_ops is already not compelling for testing
containment where there is a lot of nesting. ISTM that
make_scalar_key() could be taught to respect that distinction. ISTM
that containment will indifferently treat the top-level keys as top
level, and the nested keys as nested, because if you're looking at
something nested you have to put a top-level key in the rhs value to
do so, and it will be marked as top level, or not top level in a
bijective fashion.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2014-05-07 21:30:45 | Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers |
Previous Message | Tom Lane | 2014-05-07 21:26:55 | Re: jsonb existence queries are misimplemented by jsonb_ops |