postgres/contrib/likeplanning
Tom Lane 0471eb1681 Because we ended up forcing an initdb for 7.0 final, we aren't going
to need this updatepgproc.sql script after all...
2000-05-05 03:11:24 +00:00
..
README Because we ended up forcing an initdb for 7.0 final, we aren't going 2000-05-05 03:11:24 +00:00
disablelike.sql Add scripts to enable/disable use of new LIKE/regexp selectivity 2000-04-16 18:41:30 +00:00
enablelike.sql Because we ended up forcing an initdb for 7.0 final, we aren't going 2000-05-05 03:11:24 +00:00

README

This directory contains two 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
----------------------

Both 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.


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.