Nevím, jestli Pg dokáže kombinovat index GiST a běžné indexy b-stromu se skenováním indexu bitmapy, ale mám podezření, že ne. Nejlepšího výsledku můžete dosáhnout bez přidání user_id sloupec k vašemu indexu GiST (a následně jeho větší a pomalejší pro další dotazy, které nepoužívají user_id ).
Jako experiment můžete:
CREATE EXTENSION btree_gist;
CREATE INDEX ix_coords_and_user_id ON test USING GIST (coords, user_id);
což pravděpodobně povede k velkému indexu, ale může tento dotaz posílit - pokud to funguje. Uvědomte si, že udržování takového indexu výrazně zpomalí INSERT a UPDATE s. Pokud zahodíte staré ix_coords vaše dotazy budou používat ix_coords_and_user_id i když nefiltrují podle user_id , ale bude pomalejší než ix_coords . Zachování obou způsobí, že INSERT a UPDATE zpomalení ještě horší.
Viz btree-gist
(Zastaralé úpravou na otázku, která otázku úplně změní; při zápisu měl uživatel vícesloupcový index, který se nyní rozdělil na dva samostatné ):
Zdá se, že nefiltrujete nebo neřadíte podle user_id , pouze create_date . Pg nebude (nemůže?) používat pouze druhý termín vícesloupcového indexu, jako je (user_id, create_date) , potřebuje také použít první položku.
Pokud chcete indexovat create_date , vytvořte pro něj samostatný index. Pokud používáte a potřebujete (user_id, create_date) index a obecně nepoužívejte pouze user_id sám, zjistěte, zda můžete obrátit pořadí sloupců. Alternativně vytvořte dva nezávislé indexy (user_id) a (create_date) . Když jsou potřeba oba sloupce, Pg může kombinovat dva nezávislé indexy pomocí skenování indexu bitmapy.