mirror of
https://github.com/postgres/postgres.git
synced 2025-11-12 05:01:15 +03:00
39b9c9f221
the old ones were not small enough to ensure r-tree and gist indexes would get picked when available. These numbers are totally bogus anyway, but in the absence of any real estimation technique, we'd like to select indexes when available ...
96 lines
2.3 KiB
C
96 lines
2.3 KiB
C
/*-------------------------------------------------------------------------
|
|
*
|
|
* geo_selfuncs.c
|
|
* Selectivity routines registered in the operator catalog in the
|
|
* "oprrest" and "oprjoin" attributes.
|
|
*
|
|
* Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
*
|
|
*
|
|
* IDENTIFICATION
|
|
* $Header: /cvsroot/pgsql/src/backend/utils/adt/geo_selfuncs.c,v 1.19 2001/02/15 17:55:17 tgl Exp $
|
|
*
|
|
* XXX These are totally bogus. Perhaps someone will make them do
|
|
* something reasonable, someday.
|
|
*
|
|
*-------------------------------------------------------------------------
|
|
*/
|
|
#include "postgres.h"
|
|
|
|
#include "utils/geo_decls.h"
|
|
|
|
|
|
/*
|
|
* Selectivity functions for rtrees. These are bogus -- unless we know
|
|
* the actual key distribution in the index, we can't make a good prediction
|
|
* of the selectivity of these operators.
|
|
*
|
|
* Note: the values used here may look unreasonably small. Perhaps they
|
|
* are. For now, we want to make sure that the optimizer will make use
|
|
* of an r-tree index if one is available, so the selectivity had better
|
|
* be fairly small.
|
|
*
|
|
* In general, rtrees need to search multiple subtrees in order to guarantee
|
|
* that all occurrences of the same key have been found. Because of this,
|
|
* the estimated cost for scanning the index ought to be higher than the
|
|
* output selectivity would indicate. rtcostestimate(), over in selfuncs.c,
|
|
* ought to be adjusted accordingly --- but until we can generate somewhat
|
|
* realistic numbers here, it hardly matters...
|
|
*/
|
|
|
|
|
|
/*
|
|
* Selectivity for operators that depend on area, such as "overlap".
|
|
*/
|
|
|
|
Datum
|
|
areasel(PG_FUNCTION_ARGS)
|
|
{
|
|
PG_RETURN_FLOAT8(0.005);
|
|
}
|
|
|
|
Datum
|
|
areajoinsel(PG_FUNCTION_ARGS)
|
|
{
|
|
PG_RETURN_FLOAT8(0.005);
|
|
}
|
|
|
|
/*
|
|
* positionsel
|
|
*
|
|
* How likely is a box to be strictly left of (right of, above, below)
|
|
* a given box?
|
|
*/
|
|
|
|
Datum
|
|
positionsel(PG_FUNCTION_ARGS)
|
|
{
|
|
PG_RETURN_FLOAT8(0.1);
|
|
}
|
|
|
|
Datum
|
|
positionjoinsel(PG_FUNCTION_ARGS)
|
|
{
|
|
PG_RETURN_FLOAT8(0.1);
|
|
}
|
|
|
|
/*
|
|
* contsel -- How likely is a box to contain (be contained by) a given box?
|
|
*
|
|
* This is a tighter constraint than "overlap", so produce a smaller
|
|
* estimate than areasel does.
|
|
*/
|
|
|
|
Datum
|
|
contsel(PG_FUNCTION_ARGS)
|
|
{
|
|
PG_RETURN_FLOAT8(0.001);
|
|
}
|
|
|
|
Datum
|
|
contjoinsel(PG_FUNCTION_ARGS)
|
|
{
|
|
PG_RETURN_FLOAT8(0.001);
|
|
}
|