Re: Unexpected (bad) performance when querying indexed JSONB column

Christian Weyer <christian(dot)weyer(at)thinktecture(dot)com> writes:
> On 01.02.15 22:06, "Josh Berkus" <josh(at)agliodbs(dot)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