From: | Christian Weyer <christian(dot)weyer(at)thinktecture(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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-02 06:31:24 |
Message-ID: | A191183A-AE61-40B7-84C5-355B7A429086@thinktecture.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
>>"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
Thanks for your insights.
This greatly helped.
-C.
From | Date | Subject | |
---|---|---|---|
Next Message | Marc Mamin | 2015-02-02 09:17:17 | Re: Why is GIN index slowing down my query? |
Previous Message | Tom Lane | 2015-02-02 03:15:45 | Re: Why is GIN index slowing down my query? |