From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Add planner support function for starts_with() |
Date: | 2021-10-09 17:23:49 |
Message-ID: | 232599.1633800229@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
When starts_with() and the equivalent ^@ operator were added, they
were plugged into the planner in only a rather half-baked way.
Selectivity estimation got taught about the operator, but the
other infrastructure associated with LIKE/regex matching wasn't
updated. This causes these operators to be planned more stupidly
than a functionally-equivalent LIKE/regex pattern [1].
With the (admittedly later) introduction of planner support functions,
it's really quite easy to do better. The attached patch adds a planner
support function for starts_with(), with these benefits:
* A condition such as "textcol ^@ constant" can now use a regular
btree index, not only an SP-GiST index, so long as the index's
collation is C. (This works just like "textcol LIKE 'foo%'".)
* "starts_with(textcol, constant)" can be optimized the same as
"textcol ^@ constant".
I also rejiggered match_pattern_prefix() a bit, with the effect
that fixed-prefix LIKE and regex patterns are now more like
starts_with() in another way: if you apply one to an SPGiST-indexed
column, you'll get an index condition using ^@ rather than two
index conditions with >= and <. That should be more efficient
at runtime, though I didn't try to do any performance testing.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
planner-support-for-starts-with-1.patch | text/x-diff | 8.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-10-09 17:59:23 | Re: starts_with, ^@ and index usage |
Previous Message | Bharath Rupireddy | 2021-10-09 16:25:21 | Re: Reword docs of feature "Remove temporary files after backend crash" |