Re: Unexpected (bad) performance when querying indexed JSONB column - Mailing list pgsql-performance

From Tom Lane
Subject Re: Unexpected (bad) performance when querying indexed JSONB column
Date
Msg-id 4791.1422829257@sss.pgh.pa.us
Whole thread Raw
In response to Re: Unexpected (bad) performance when querying indexed JSONB column  (Christian Weyer <christian.weyer@thinktecture.com>)
Responses Re: Unexpected (bad) performance when querying indexed JSONB column
List pgsql-performance
Christian Weyer <christian.weyer@thinktecture.com> writes:
> On 01.02.15 22:06, "Josh Berkus" <josh@agliodbs.com> wrote:
>> Please send us the output of EXPLAIN ( ANALYZE ON, BUFFERS ON ) so that
>> we can see what the query is actually doing, rather than just what the
>> plan was.

> Sure. Here we go:

> "Bitmap Heap Scan on articles  (cost=16.25..135.64 rows=33 width=427)
> (actual time=6.425..43.603 rows=18584 loops=1)"
> "  Recheck Cond: (data @> ‘{"locked": true}'::jsonb)"
> "  Heap Blocks: exact=1496"
> "  Buffers: shared hit=1504"
> "  ->  Bitmap Index Scan on idx_data  (cost=0.00..16.24 rows=33 width=0)
> (actual time=6.090..6.090 rows=18584 loops=1)"
> "        Index Cond: (data @> ‘{"locked": true}'::jsonb)"
> "        Buffers: shared hit=8"
> "Planning time: 0.348 ms"
> "Execution time: 47.788 ms"

So that's showing a runtime of 48 ms, not 900.  For retrieving 18584
rows, doesn't sound that bad to me.

(If the planner had had a better rowcount estimate, it'd likely have
not bothered with the index at all but just done a seqscan.  This is
a consequence of the lack of any very useful stats for JSONB columns,
which is something we hope to address soon; but it's not done in 9.4
and likely won't be in 9.5 either ...)

            regards, tom lane


pgsql-performance by date:

Previous
From: Christian Weyer
Date:
Subject: Re: Unexpected (bad) performance when querying indexed JSONB column
Next
From: AlexK987
Date:
Subject: Why is GIN index slowing down my query?