From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Christian Weyer <christian(dot)weyer(at)thinktecture(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Unexpected (bad) performance when querying indexed JSONB column |
Date: | 2015-02-01 22:20:57 |
Message-ID: | 4791.1422829257@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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
From | Date | Subject | |
---|---|---|---|
Next Message | AlexK987 | 2015-02-01 22:32:21 | Why is GIN index slowing down my query? |
Previous Message | Christian Weyer | 2015-02-01 21:19:29 | Re: Unexpected (bad) performance when querying indexed JSONB column |