Nie wiem, czy Pg może łączyć indeks GiST i zwykłe indeksy b-drzewa ze skanowaniem indeksu bitmapy, ale podejrzewam, że nie. Możesz uzyskać najlepszy możliwy wynik bez dodawania user_id kolumnę do indeksu GiST (i w konsekwencji powiększając ją i zwalniając dla innych zapytań, które nie używają user_id ).
W ramach eksperymentu możesz:
CREATE EXTENSION btree_gist;
CREATE INDEX ix_coords_and_user_id ON test USING GIST (coords, user_id);
co prawdopodobnie spowoduje duży indeks, ale może wzmocnić to zapytanie - jeśli zadziała. Pamiętaj, że utrzymanie takiego indeksu znacznie spowolni INSERT i UPDATE s. Jeśli porzucisz stary ix_coords Twoje zapytania będą używać ix_coords_and_user_id nawet jeśli nie filtrują według user_id , ale będzie wolniejszy niż ix_coords . Zachowanie obu spowoduje, że INSERT i UPDATE spowolnienie jeszcze gorsze.
Zobacz btree-gist
(Przestarzałe przez edycję pytania, które całkowicie zmienia pytanie; po zapisaniu użytkownik miał indeks wielokolumnowy, został teraz podzielony na dwa oddzielne ):
Wygląda na to, że nie filtrujesz ani nie sortujesz według user_id , tylko create_date . Pg nie będzie (nie może?) używać tylko drugiego terminu indeksu wielokolumnowego, takiego jak (user_id, create_date) , wymaga również użycia pierwszego elementu.
Jeśli chcesz zindeksować create_date , utwórz dla niego osobny indeks. Jeśli używasz i potrzebujesz (user_id, create_date) indeksuj i zazwyczaj nie używaj tylko user_id sam, sprawdź, czy możesz odwrócić kolejność kolumn. Alternatywnie utwórz dwa niezależne indeksy, (user_id) i (create_date) . Gdy potrzebne są obie kolumny, Pg może połączyć dwa niezależne indeksy za pomocą skanowania indeksu bitmapy.
