From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Matt Friedman" <matt(at)sprynewmedia(dot)com> |
Cc: | "PgSql General List" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: ~* OR LIKE? |
Date: | 2001-03-23 22:51:56 |
Message-ID: | 10820.985387916@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Matt Friedman" <matt(at)daart(dot)ca> writes:
> What's the relative performance for: "IN" "LIKE" or "~*"?
If you don't have an index on the target column, or if the pattern is
not constant (eg you took it from another table), then these will all
reduce to sequential-scan-and-examine-every-tuple. Simple equality
comparisons will take a little less CPU time than pattern matches, but
the tuple retrieval costs are going to dominate everything anyway.
In short: it hardly matters unless you can use an indexscan.
IN ('foo','bar','baz') reduces to x = 'foo' OR x = 'bar' OR x = 'baz'.
This can be done by a series of indexscans (one index probe per OR
clause), so it's pretty quick for small numbers of alternatives.
Case-sensitive LIKE and ~ can use indexscans if (at least part of) the
constant pattern is left-anchored. For example, x LIKE 'foo%bar' can
only match values beginning with 'foo', so an index scan over the range
of such values can be used. In regexp notation this'd be a pattern
anchored left with ^.
The above breaks down for case-insensitive matching, and it also breaks
down in non-C locales, where string sort ordering may not match the
semantics of pattern prefixes closely enough. So in those cases you are
back to sequential scan.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Christian Marschalek | 2001-03-23 23:33:57 | Database shutdown |
Previous Message | Tom Lane | 2001-03-23 22:42:37 | Re: Vacuum VS Vacuum Analyze |