mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-31 00:57:22 +02:00
52 lines
2.4 KiB
Plaintext
52 lines
2.4 KiB
Plaintext
This directory contains three SQL scripts that control use of some new
|
|
code for planning/optimizing queries containing LIKE and
|
|
regular-expression operators. This code was added to Postgres 7.0 late in
|
|
beta test, and it hasn't gotten enough testing to warrant turning it on by
|
|
default in release 7.0 (although it probably will become default in 7.1).
|
|
So, here are some scripts to enable and disable it. You may want to run
|
|
these scripts if you have problems with the planner choosing bad plans for
|
|
queries involving LIKE or regexps in WHERE clauses.
|
|
|
|
|
|
HOW TO USE THE SCRIPTS
|
|
----------------------
|
|
|
|
All three scripts must be run as the Postgres superuser. The easiest
|
|
way to run an SQL script is
|
|
psql -f scriptfile databasename
|
|
or you can start psql interactively and enter
|
|
\i scriptfile
|
|
|
|
enablelike.sql enables use of the new planning code in the database in
|
|
which it is run. If you run it in template1, all subsequently-created
|
|
databases will use the new code by default.
|
|
|
|
disablelike.sql reverts to the old planning code for LIKE, in the database
|
|
in which it is run. If you run it in template1, all subsequently-created
|
|
databases will use the old code by default.
|
|
|
|
If your database was initdb'd with release 7.0beta5, you need to run
|
|
updatepgproc.sql before you can run enablelike.sql. Databases initdb'd
|
|
with 7.0RC1 or later already have pg_proc entries for the new code, so
|
|
updatepgproc.sql is unnecessary for them. If enablelike.sql produces
|
|
errors like "No procedure with name regexeqsel", then you need to run
|
|
updatepgproc.sql.
|
|
|
|
|
|
WHAT IT DOES
|
|
------------
|
|
|
|
These scripts install (or disable) new code for "selectivity estimation"
|
|
of LIKE and regexp operators. Selectivity estimation determines the
|
|
estimated number of rows produced by a query or subquery, and that in turn
|
|
determines the kind of plan the planner will use. The old selectivity
|
|
estimator ignored the pattern being searched for and just produced the
|
|
same estimate as for an "=" operator, which of course was usually too low
|
|
for a wildcard match. The new code has some knowledge of pattern matching
|
|
rules and generates an estimate based on the number of fixed characters and
|
|
wildcards present in the pattern. Also, if the pattern has a fixed prefix
|
|
that must be matched (such as LIKE 'foo%' or ~ '^foo'), an appropriate
|
|
range-query selectivity estimate is produced and factored into the result.
|
|
|
|
If you want to look at the code itself, see src/backend/utils/adt/selfuncs.c.
|