Christian Weyer <christian.we...@thinktecture.com> writes:
> On 01.02.15 22:06, "Josh Berkus" <j...@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
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
