PgがGiSTインデックスと通常のbツリーインデックスをビットマップインデックススキャンと組み合わせることができるかどうかはわかりませんが、そうではないと思います。 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 s。古いix_coordsを削除した場合 クエリはix_coords_and_user_idを使用します user_idでフィルタリングしなくても 、ただし、ix_coordsよりも遅くなります 。両方を保持すると、INSERTが作成されます およびUPDATE 減速はさらに悪化します。
btree-gist を参照してください
（質問を完全に変更する質問への編集によって廃止されました。ユーザーが複数列のインデックスを持っていた場合、ユーザーは2つの別々のインデックスに分割されました ）：
user_idでフィルタリングや並べ替えを行っていないようです 、create_dateのみ 。 Pgは、(user_id, create_date)のような複数列インデックスの2番目の用語のみを使用しません（できませんか？） 、最初のアイテムも使用する必要があります。
create_dateにインデックスを付ける場合 、そのための個別のインデックスを作成します。 (user_id, create_date)を使用して必要な場合 インデックスを作成し、通常はuser_idだけを使用しないでください 単独で、列の順序を逆にできるかどうかを確認してください。代わりに、2つの独立したインデックス(user_id)を作成します および(create_date) 。両方の列が必要な場合、Pgはビットマップインデックススキャンを使用して2つの独立したインデックスを組み合わせることができます。