>>"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
AlexK987 writes:
> This is a realistic case: everyone have Python and Java skills, but PostGis
> and Haskell and Closure are rare. If we are looking for a person that has
> all the skills required for a task (array[1, 15]), that is "skills <@
> array[1, 15] " and not the opposite, right?
One of u
Tom,
Oops, you were absolutely right: I needed to use @> instead of <@. Thanks
again!
--
View this message in context:
http://postgresql.nabble.com/Why-is-GIN-index-slowing-down-my-query-tp5836319p5836327.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.
--
Sen
Tom,
This is a realistic case: everyone have Python and Java skills, but PostGis
and Haskell and Closure are rare. If we are looking for a person that has
all the skills required for a task (array[1, 15]), that is "skills <@
array[1, 15] " and not the opposite, right?
Also can you explain why " e
AlexK987 writes:
> I've created a GIN index on an INT[] column, but it slows down the selects.
> Here is my table:
> create table talent(person_id INT NOT NULL,
> skills INT[] NOT NULL);
> insert into talent(person_id, skills)
> select generate_series, array[0, 1] || generate_series
> from gener
I've created a GIN index on an INT[] column, but it slows down the selects.
Here is my table:
create table talent(person_id INT NOT NULL,
skills INT[] NOT NULL);
insert into talent(person_id, skills)
select generate_series, array[0, 1] || generate_series
from generate_series(3, 1048575);
create
Christian Weyer writes:
> On 01.02.15 22:06, "Josh Berkus" 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..1
On 01.02.15 22:06, "Josh Berkus" 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 Hea
On 01/30/2015 05:34 PM, Jim Nasby wrote:
> On 1/30/15 2:26 PM, Josh Berkus wrote:
>> This would probably work because there aren't a lot of data structures
>> where people would have the same key:value pair in different locations
>> in the JSON, and care about it stats-wise. Alternatetly, if the s
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
10 matches
Mail list logo
