Jag vet inte om Pg kan kombinera ett GiST-index och vanliga b-trädindex med en bitmappsindexavsökning, men jag misstänker att det inte är det. Du kanske får det bästa resultatet du kan utan att lägga till ett user_id kolumnen till ditt GiST-index (och följaktligen göra det större och långsammare för andra frågor som inte använder user_id ).
Som ett experiment kan du:
CREATE EXTENSION btree_gist;
CREATE INDEX ix_coords_and_user_id ON test USING GIST (coords, user_id);
vilket sannolikt kommer att resultera i ett stort index, men kan förstärka den frågan - om den fungerar. Var medveten om att underhåll av ett sådant index kommer att avsevärt sakta ner INSERT och UPDATE s. Om du tappar den gamla ix_coords dina frågor kommer att använda ix_coords_and_user_id även om de inte filtrerar på user_id , men det kommer att vara långsammare än ix_coords . Om du behåller båda blir INSERT och UPDATE avmattning ännu värre.
Se btree-gist
(Föråldrad genom redigering av fråga som ändrar frågan fullständigt; när den skrevs hade användaren ett index med flera kolumner de har nu delat upp i två separata ):
Du verkar inte filtrera eller sortera på user_id , endast create_date . Pg kommer inte (kan inte?) bara använda den andra termen i ett index med flera kolumner som (user_id, create_date) , det måste också användas av det första objektet.
Om du vill indexera create_date , skapa ett separat index för det. Om du använder och behöver (user_id, create_date) index och använder vanligtvis inte bara user_id ensam, se om du kan vända kolumnordningen. Skapa alternativt två oberoende index, (user_id) och (create_date) . När båda kolumnerna behövs kan Pg kombinera de två oberoende indexen med hjälp av en bitmappsindexskanning.