pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedUnexpected (bad) performance when querying indexed JSONB column
6+ messages / 3 participants
[nested] [flat]
* Unexpected (bad) performance when querying indexed JSONB column
@ 2015-01-31 16:00 Christian Weyer <christian.weyer@thinktecture.com>
0 siblings, 0 replies; 6+ messages in thread
From: Christian Weyer @ 2015-01-31 16:00 UTC (permalink / raw)
To: pgsql-performance
Hi all,
The pg version in question is the latest 9.4., running on Windows.
For testing out the NoSQL features of pg I have a simple table called ‘articles’ with a column called ‘data’.
There is an index on ‘data’ like this:
CREATE INDEX idx_data ON articles USING gin (data jsonb_path_ops);
The current test data set has 32570 entires of JSON docs like this:
{
"title": "Foo Bar",
"locked": true,
"valid_until": "2049-12-31T00:00:00",
"art_number": 12345678,
"valid_since": "2013-10-05T00:00:00",
"number_valid": false,
"combinations": {
"var1": "4711",
"var2": "4711",
"var3": "0815",
"int_art_number": "000001"
}
}
Nothing too complex, I think.
When I run a simple query:
SELECT data #>> ‘{"title"}'
FROM articles
WHERE data @> '{ “locked" : true }';
Reproducingly, it takes approx. 900ms to get the results back.
Honestly, I was expecting a much faster query.
Any opinions on this?
Thanks,
-C.
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Unexpected (bad) performance when querying indexed JSONB column
@ 2015-01-31 19:02 Christian Weyer <christian.weyer@thinktecture.com>
0 siblings, 1 reply; 6+ messages in thread
From: Christian Weyer @ 2015-01-31 19:02 UTC (permalink / raw)
To: pgsql-performance
Just checked: the execution time is the same when I drop the index.
Execution plan with index:
---
"Bitmap Heap Scan on articles (cost=16.25..135.64 rows=33 width=427)"
" Recheck Cond: (data @> '{"locked": true}'::jsonb)"
" -> Bitmap Index Scan on idx_data (cost=0.00..16.24 rows=33 width=0)"
" Index Cond: (data @> '{"locked": true}'::jsonb)"
---
And without the index:
---
"Seq Scan on articles (cost=0.00..2289.21 rows=33 width=427)"
" Filter: (data @> '{"locked": true}'::jsonb)"
---
-C.
From: Christian Weyer
Date: Samstag, 31. Januar 2015 17:00
To: "pgsql-performance@postgresql.org<mailto:pgsql-performance@postgresql.org>"
Subject: [PERFORM] Unexpected (bad) performance when querying indexed JSONB column
Hi all,
The pg version in question is the latest 9.4., running on Windows.
For testing out the NoSQL features of pg I have a simple table called ‘articles’ with a column called ‘data’.
There is an index on ‘data’ like this:
CREATE INDEX idx_data ON articles USING gin (data jsonb_path_ops);
The current test data set has 32570 entires of JSON docs like this:
{
"title": "Foo Bar",
"locked": true,
"valid_until": "2049-12-31T00:00:00",
"art_number": 12345678,
"valid_since": "2013-10-05T00:00:00",
"number_valid": false,
"combinations": {
"var1": "4711",
"var2": "4711",
"var3": "0815",
"int_art_number": "000001"
}
}
Nothing too complex, I think.
When I run a simple query:
SELECT data #>> ‘{"title"}'
FROM articles
WHERE data @> '{ “locked" : true }';
Reproducingly, it takes approx. 900ms to get the results back.
Honestly, I was expecting a much faster query.
Any opinions on this?
Thanks,
-C.
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Unexpected (bad) performance when querying indexed JSONB column
@ 2015-02-01 21:06 Josh Berkus <josh@agliodbs.com>
parent: Christian Weyer <christian.weyer@thinktecture.com>
0 siblings, 1 reply; 6+ messages in thread
From: Josh Berkus @ 2015-02-01 21:06 UTC (permalink / raw)
To: Christian Weyer <christian.weyer@thinktecture.com>; pgsql-performance
On 01/31/2015 11:02 AM, Christian Weyer wrote:
> Just checked: the execution time is the same when I drop the index.
>
> Execution plan with index:
> ---
> "Bitmap Heap Scan on articles (cost=16.25..135.64 rows=33 width=427)"
> " Recheck Cond: (data @> '{"locked": true}'::jsonb)"
> " -> Bitmap Index Scan on idx_data (cost=0.00..16.24 rows=33 width=0)"
> " Index Cond: (data @> '{"locked": true}'::jsonb)"
> ---
>
> And without the index:
> ---
> "Seq Scan on articles (cost=0.00..2289.21 rows=33 width=427)"
> " Filter: (data @> '{"locked": true}'::jsonb)"
> ---
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.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Unexpected (bad) performance when querying indexed JSONB column
@ 2015-02-01 21:19 Christian Weyer <christian.weyer@thinktecture.com>
parent: Josh Berkus <josh@agliodbs.com>
0 siblings, 1 reply; 6+ messages in thread
From: Christian Weyer @ 2015-02-01 21:19 UTC (permalink / raw)
To: Josh Berkus <josh@agliodbs.com>; pgsql-performance
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.
>
>--
>Josh Berkus
>PostgreSQL Experts Inc.
>http://pgexperts.com
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"
Thanks for looking into this.
-C.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Unexpected (bad) performance when querying indexed JSONB column
@ 2015-02-01 22:20 Tom Lane <tgl@sss.pgh.pa.us>
parent: Christian Weyer <christian.weyer@thinktecture.com>
0 siblings, 1 reply; 6+ messages in thread
From: Tom Lane @ 2015-02-01 22:20 UTC (permalink / raw)
To: Christian Weyer <christian.weyer@thinktecture.com>; +Cc: Josh Berkus <josh@agliodbs.com>; 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
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Unexpected (bad) performance when querying indexed JSONB column
@ 2015-02-02 06:31 Christian Weyer <christian.weyer@thinktecture.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 6+ messages in thread
From: Christian Weyer @ 2015-02-02 06:31 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Josh Berkus <josh@agliodbs.com>; 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.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2015-02-02 06:31 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2015-01-31 16:00 Unexpected (bad) performance when querying indexed JSONB column Christian Weyer <christian.weyer@thinktecture.com>
2015-01-31 19:02 Re: Unexpected (bad) performance when querying indexed JSONB column Christian Weyer <christian.weyer@thinktecture.com>
2015-02-01 21:06 ` Josh Berkus <josh@agliodbs.com>
2015-02-01 21:19 ` Christian Weyer <christian.weyer@thinktecture.com>
2015-02-01 22:20 ` Tom Lane <tgl@sss.pgh.pa.us>
2015-02-02 06:31 ` Christian Weyer <christian.weyer@thinktecture.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox