My knowledge is limited in this area, and the documentation covers this specific dynamic only minimally, but for certain attempting to perform an un-anchored regexp match using a btree index is impossible.
These leaves to avenues to explore.
1) See if a start-of-string anchor will make the btree index usable
- CREATE INDEX CONCURRENTLY ix_inodes_checksum_st_size ON gorfs.inodes USING btree ("checksum_md5","st_size");
This one was used.
IMO you are leaving too much infomation encoded in the full_path. I'd personally setup triggers to parse out the components on insert/update into fields and then index those fields. In fact I'd probably use some form of inheritance or other one-to-one relationship here.
I guess it is documented, I just needed to look a bit more.
"""
The optimizer can also use a B-tree index for queries involving the pattern matching operators LIKE and ~ if the pattern is a constant and is anchored to the beginning of the string — for example, col LIKE 'foo%' or col ~ '^foo', but not col LIKE '%bar'. However, if your database does not use the C locale you will need to create the index with a special operator class to support indexing of pattern-matching queries; see Section 11.9 below. It is also possible to use B-tree indexes for ILIKE and ~*, but only if the pattern starts with non-alphabetic characters, i.e., characters that are not affected by upper/lower case conversion.
