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
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
Tomas,
Thank you for a very useful reply. Right now I do not have a case of poor
performance caused by strong data skew which is not properly reflected in
statistics. I was being defensive, trying to prevent every possible thing
that might go wrong.
--
View this message in context:
http://post
The documentation states that "The extent of analysis can be controlled by
adjusting the default_statistics_target configuration variable". It looks
like I can tell Postgres to create more histograms with more bins, and more
distinct values. This implicitly means that Postgres will use a larger
ran