Today Seven Databases in Seven Weeks introduced me to per-operator indexes.

You can index strings for pattern matching the previous queries by creating a text_pattern_ops operator class index, as long as the values are indexed in lowercase.

CREATE INDEX moves_title_pattern ON movies (
    (lower(title) text_pattern_ops);

We used the text_pattern_ops because the title is of type text. If you need to index varchars, chars, or names, use the related ops: varchar_pattern_ops, bpchar_pattern_ops, and name_pattern_ops.

I find the example really confusing. Why is it useful to do this?

If the column is type text, wouldn't the other types (varchar, char, name) be cast to to text before being used as a search value?

How does that index behave differently from one using the default operator?

CREATE INDEX moves_title_pattern ON movies (lower(title));

1 Answer 1


The documentation often gives you an answer to such questions. Like in this case, too:

The operator classes text_pattern_ops, varchar_pattern_ops, and bpchar_pattern_ops support B-tree indexes on the types text, varchar, and char respectively. The difference from the default operator classes is that the values are compared strictly character by character rather than according to the locale-specific collation rules. This makes these operator classes suitable for use by queries involving pattern matching expressions (LIKE or POSIX regular expressions) when the database does not use the standard "C" locale. As an example, you might index a varchar column like this:

CREATE INDEX test_index ON test_table (col varchar_pattern_ops);

Note that you should also create an index with the default operator class if you want queries involving ordinary <, <=, >, or >= comparisons to use an index. Such queries cannot use the xxx_pattern_ops operator classes. (Ordinary equality comparisons can use these operator classes, however.) It is possible to create multiple indexes on the same column with different operator classes.

The documentation goes on to say:

If you do use the C locale, you do not need the xxx_pattern_ops operator classes, because an index with the default operator class is usable for pattern-matching queries in the C locale.

You can check your locale as follows (it is likely to be UTF8 rather than "C"):

postgres=> show lc_collate;
  • 1
    Aha! I did read that, but found it hard to follow so didn't take it in. Would you say the useful usefulness of text_pattern_ops depends on the locale? Looks like it would benefit me because my locale is 'en_US.UTF-8' (not 'C'), so pattern queries can't use the default index. Commented Nov 22, 2013 at 18:28
  • Exactly. I would add (but this is only speculation) that with data staying inside the basic ASCII characters the default operator class is just as good - at least I see queries with LIKE 'something%' using such indexes. Commented Nov 22, 2013 at 18:33
  • 8
    @dezso: If you have seen a LIKE query using a plain b-tree index, then the db must be using the C locale. Or the index is defined with the COLLATE "POSIX" (or COLLATE "C") and the query specifies a matching COLLATION. With any other collation, the order of the index does not match the locale rules and therefore cannot be used for pattern matching. Commented Nov 22, 2013 at 18:55
  • 1
    @ErwinBrandstetter I have to confirm, you are right. Commented Mar 10, 2014 at 9:23
  • 3
    @StopHarmingMonica you get the correct response (and no error), just the query will be possibly slower, not being able to use the index. Commented Nov 11, 2019 at 15:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.