mirror of
https://github.com/postgres/postgres.git
synced 2025-07-30 11:03:19 +03:00
If we cannot get a real estimate for the selectivity of a range query,
use a default value that's fairly small. We were generating a result of about 0.1, but I think 0.01 is probably better --- want to encourage use of an indexscan in this situation.
This commit is contained in:
@ -8,7 +8,7 @@
|
|||||||
*
|
*
|
||||||
*
|
*
|
||||||
* IDENTIFICATION
|
* IDENTIFICATION
|
||||||
* $Header: /cvsroot/pgsql/src/backend/optimizer/path/clausesel.c,v 1.31 2000/03/17 02:36:14 tgl Exp $
|
* $Header: /cvsroot/pgsql/src/backend/optimizer/path/clausesel.c,v 1.32 2000/03/23 00:58:36 tgl Exp $
|
||||||
*
|
*
|
||||||
*-------------------------------------------------------------------------
|
*-------------------------------------------------------------------------
|
||||||
*/
|
*/
|
||||||
@ -194,9 +194,11 @@ clauselist_selectivity(Query *root,
|
|||||||
else
|
else
|
||||||
{
|
{
|
||||||
/* One or both is probably a default estimate,
|
/* One or both is probably a default estimate,
|
||||||
* so punt and just merge them in generically.
|
* so supply a default estimate for the selectivity
|
||||||
|
* of the range query. We rather optimistically assume
|
||||||
|
* that the range is tight...
|
||||||
*/
|
*/
|
||||||
s1 *= rqlist->hibound * rqlist->lobound;
|
s1 *= 0.01;
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
else
|
else
|
||||||
|
Reference in New Issue
Block a user