mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-12-09 08:10:09 +08:00
|
|
||
|---|---|---|
| .. | ||
| disablelike.sql | ||
| enablelike.sql | ||
| 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.