mirror of
https://github.com/postgres/postgres.git
synced 2025-07-02 09:02:37 +03:00
Re-run pgindent, fixing a problem where comment lines after a blank
comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
This commit is contained in:
@ -9,7 +9,7 @@
|
||||
*
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* $PostgreSQL: pgsql/src/backend/optimizer/path/indxpath.c,v 1.192 2005/11/14 23:54:17 tgl Exp $
|
||||
* $PostgreSQL: pgsql/src/backend/optimizer/path/indxpath.c,v 1.193 2005/11/22 18:17:12 momjian Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
@ -262,8 +262,8 @@ find_usable_indexes(PlannerInfo *root, RelOptInfo *rel,
|
||||
* to imply the predicate. If so, we could use the index in the
|
||||
* current context.
|
||||
*
|
||||
* We set useful_predicate to true iff the predicate was proven using the
|
||||
* current set of clauses. This is needed to prevent matching a
|
||||
* We set useful_predicate to true iff the predicate was proven using
|
||||
* the current set of clauses. This is needed to prevent matching a
|
||||
* predOK index to an arm of an OR, which would be a legal but
|
||||
* pointlessly inefficient plan. (A better plan will be generated by
|
||||
* just scanning the predOK index alone, no OR.)
|
||||
@ -524,19 +524,19 @@ choose_bitmap_and(PlannerInfo *root, RelOptInfo *rel, List *paths)
|
||||
* always take the first, and sequentially add on paths that result in a
|
||||
* lower estimated cost.
|
||||
*
|
||||
* We also make some effort to detect directly redundant input paths, as can
|
||||
* happen if there are multiple possibly usable indexes. For this we look
|
||||
* only at plain IndexPath inputs, not at sub-OR clauses. And we consider
|
||||
* an index redundant if all its index conditions were already used by
|
||||
* earlier indexes. (We could use predicate_implied_by to have a more
|
||||
* intelligent, but much more expensive, check --- but in most cases
|
||||
* We also make some effort to detect directly redundant input paths, as
|
||||
* can happen if there are multiple possibly usable indexes. For this we
|
||||
* look only at plain IndexPath inputs, not at sub-OR clauses. And we
|
||||
* consider an index redundant if all its index conditions were already
|
||||
* used by earlier indexes. (We could use predicate_implied_by to have a
|
||||
* more intelligent, but much more expensive, check --- but in most cases
|
||||
* simple pointer equality should suffice, since after all the index
|
||||
* conditions are all coming from the same RestrictInfo lists.)
|
||||
*
|
||||
* XXX is there any risk of throwing away a useful partial index here because
|
||||
* we don't explicitly look at indpred? At least in simple cases, the
|
||||
* partial index will sort before competing non-partial indexes and so it
|
||||
* makes the right choice, but perhaps we need to work harder.
|
||||
* XXX is there any risk of throwing away a useful partial index here
|
||||
* because we don't explicitly look at indpred? At least in simple cases,
|
||||
* the partial index will sort before competing non-partial indexes and so
|
||||
* it makes the right choice, but perhaps we need to work harder.
|
||||
*
|
||||
* Note: outputting the selected sub-paths in selectivity order is a good
|
||||
* thing even if we weren't using that as part of the selection method,
|
||||
@ -920,8 +920,8 @@ check_partial_indexes(PlannerInfo *root, RelOptInfo *rel)
|
||||
* index. For now, the test only uses restriction clauses (those in
|
||||
* baserestrictinfo). --Nels, Dec '92
|
||||
*
|
||||
* XXX as of 7.1, equivalence class info *is* available. Consider improving
|
||||
* this code as foreseen by Nels.
|
||||
* XXX as of 7.1, equivalence class info *is* available. Consider
|
||||
* improving this code as foreseen by Nels.
|
||||
*/
|
||||
|
||||
foreach(ilist, rel->indexlist)
|
||||
|
Reference in New Issue
Block a user