Question

I have a need to store data using the HSTORE type and index by key.

CREATE INDEX ix_product_size ON product(((data->'Size')::INT))
CREATE INDEX ix_product_color ON product(((data->'Color')))
etc.

What are the practical limitations of using expression indexes? In my case, there could be several hundred different types of data, hence several hundred expression indexes. Every insert, update, and select query will have to process against these indexes in order to pick the correct one.

Answer 1

I’ve never played with hstore, but I do something similar when I need an EAV column, e.g.:

create index on product_eav (eav_value) where (eav_type = 'int');

The limitation in doing so is that you need to be explicit in your query to make use of it, i.e. this query would not make use of the above index:

select product_id
from product_eav
where eav_name = 'size'
and eav_value = :size;

But this one would:

select product_id
from product_eav
where eav_name = 'size'
and eav_value = :size
and type = 'int';

In your example it should likely be more like:

create index on product ((data->'size')::int) where (data->'size' is not null);

This should avoid adding a reference to the index when there is no size entry. Depending on the PG version you’re using the query may need to be modified like so:

select product_id
from products
where data->'size' is not null
and data->'size' = :size;

Another big difference between regular and partial index is that the latter cannot enforce a unique constraint in a table definition. This will succeed:

create unique index foo_bar_key on foo (bar) where (cond);

The following won’t:

alter table foo add constraint foo_bar_key unique (bar) where (cond);

But this will:

alter table foo add constraint foo_bar_excl exclude (bar with =) where (cond);