What to index on queries with lots of columns in the WHERE clause

Question

Building a search engine for an apartment site and I\'m not sure how to index the apartments table.

Example of queries:

• ...WHERE c

Answer 1

Postgres 9.6 provides a new extension to address your conundrum precisely:

bloom index

From the same authors who brought trigram indexes or text search to Postgres (among other things).

A single bloom index on all involved columns works well for any combination of them in the WHERE clause - even if not as well as a separate btree indexes on each column. But a single index is much smaller and cheaper to maintain than many indexes. You'll have to weigh costs and benefits.

A bloom index excels for many index columns that can be combined in many ways.

I might combine a bloom index as "catch-all" with some tailored multicolumn btree indexes to optimize the most common combinations (along the guidelines provided by @Laurenz) and some single column indexes on the most frequently queried columns.

Some more explanation:

• Is a composite index also good for queries on the first field?

The feature is new and there are some important limitations. Quoting the manual:

• Only operator classes for int4 and text are included with the module.

• Only the = operator is supported for search. But it is possible to add support for arrays with union and intersection operations in the future.

So not for published_at, which looks like a date (but you could still extract an EPOCH and index that) and only for equality predicates.

After creating the extension (once per DB):

CREATE EXTENSION bloom;

Create a bloom index:

CREATE INDEX tbl_bloomidx
ON tbl USING bloom (area_id, city_id, size, rooms, ad_type);  -- many more columns?

And some others:

CREATE INDEX tbl_published_at ON tbl (published_at);
CREATE INDEX tbl_published_at ON tbl (price);
-- some popular combinations...

The manual has some examples comparing bloom, multicolumn and single-column btree indexes. Very insightful.