2017-02-14 14 views
0

ストアのテーブル(〜10kレコード)とスケジュールのテーブル(〜200kレコード)があれば、使用するプランナを作成してインデックスを作成しようとしていますが、これまで無視しています。Postgres index 2列の条件付き

select * from stores str 
    inner join schedule sch on sch.store_id = str.store_id 
where sch.open is true and sch.tables > 0 

create index sch_open_tables_idx on schedule(open, tables) where open is true and tables > 0 

正しい方法がありますか?

+0

インデックスが無視されていると思われ、無視されていると思われるlog/result/testを含めることができますか? – Alfabravo

+1

[postgresql-performance](http://stackoverflow.com/tags/postgresql-performance/info)を読んで**あなたの質問を** [編集] **し、不足している情報を提供してください。 –

+1

少なくとも、インデックスに 'open'カラムは必要ありません(常に' true'になります)が、 'store_id'が役に立ちます(そのインデックスの最初のカラムとして)。また、クエリとインデックスの両方で 'where sch.open'を使うことができます。' true true'は必要ありません。(どちらも害はありません。 – pozs

答えて

1

あなたが必要とするインデックスである必要はありません。

create index sch_open_tables_id on schedule(store_id) 
where open and tables > 0; 

store_idですがおそらくstoresテーブルの主キーなので、既にインデックスがあります。そうでない場合:

create index store_id on stores(store_id); 
0

これらは、2つの指数は2つのテーブルがあり、その使用 - それぞれに1つずつ、とにかくこのような小さなテーブルは、部分的インデックス

EXPLAIN select * from stores str 
    inner join schedule sch USING (store_id) 
where sch.open is true and tables > 0; 

create index sch_open_idx on schedule(store_id) where open is true; 
create index str_tables_idx on stores(store_id) where tables > 0; 

vacuum analyze stores; 
vacuum analyze schedule; 

EXPLAIN select * from stores str 
    inner join schedule sch USING (store_id) 
where sch.open is true and tables > 0; 
+0

しかし、なぜ 'tables'列が' stores'に属すると思いますか? –

+0

列テーブルはスケジュールに属します。 – mallix