Не знам дали Pg може да комбинира GiST индекс и обикновени b-tree индекси със сканиране на растерни индекси, но подозирам, че не. Може да получите най-добрия възможен резултат без добавяне на user_id колона към вашия GiST индекс (и следователно го прави по-голям и по-бавен за други заявки, които не използват user_id ).
Като експеримент бихте могли:
CREATE EXTENSION btree_gist;
CREATE INDEX ix_coords_and_user_id ON test USING GIST (coords, user_id);
което вероятно ще доведе до голям индекс, но може да засили тази заявка - ако работи. Имайте предвид, че поддържането на такъв индекс значително ще забави INSERT и UPDATE с. Ако изпуснете старите ix_coords вашите заявки ще използват ix_coords_and_user_id дори и да не филтрират по user_id , но ще бъде по-бавен от ix_coords . Запазването на двете ще направи INSERT и UPDATE забавяне още по-лошо.
Вижте btree-gist
(Остарял от редакция на въпрос, която напълно променя въпроса; когато е написан, потребителят е имал индекс с много колони, те сега са разделени на два отделни ):
Изглежда, че не филтрирате или сортирате по user_id , само create_date . Pg няма (не може?) да използва само втория член на индекс с няколко колони като (user_id, create_date) , трябва да използва и първия елемент.
Ако искате да индексирате create_date , създайте отделен индекс за него. Ако използвате и имате нужда от (user_id, create_date) индекс и обикновено не използвайте само user_id сам, вижте дали можете да обърнете реда на колоните. Алтернативно създайте два независими индекса, (user_id) и (create_date) . Когато са необходими и двете колони, Pg може да комбинира двата независими индекса с помощта на сканиране на растерни индекси.
