mirror of
https://github.com/postgres/postgres.git
synced 2025-08-27 07:42:10 +03:00
Fix various typos and spelling mistakes in code comments
Author: Justin Pryzby Discussion: https://postgr.es/m/20220411020336.GB26620@telsasoft.com
This commit is contained in:
@@ -1976,8 +1976,8 @@ compute_cpu_sort_cost(PlannerInfo *root, List *pathkeys, int nPresortedKeys,
|
||||
* by calling estimate_num_groups_incremental(), which estimates the
|
||||
* group size for "new" pathkeys.
|
||||
*
|
||||
* Note: estimate_num_groups_incremntal does not handle fake Vars, so use
|
||||
* a default estimate otherwise.
|
||||
* Note: estimate_num_groups_incremental does not handle fake Vars, so
|
||||
* use a default estimate otherwise.
|
||||
*/
|
||||
if (!has_fake_var)
|
||||
nGroups = estimate_num_groups_incremental(root, pathkeyExprs,
|
||||
@@ -6471,7 +6471,7 @@ compute_bitmap_pages(PlannerInfo *root, RelOptInfo *baserel, Path *bitmapqual,
|
||||
exact_pages = heap_pages - lossy_pages;
|
||||
|
||||
/*
|
||||
* If there are lossy pages then recompute the number of tuples
|
||||
* If there are lossy pages then recompute the number of tuples
|
||||
* processed by the bitmap heap node. We assume here that the chance
|
||||
* of a given tuple coming from an exact page is the same as the
|
||||
* chance that a given page is exact. This might not be true, but
|
||||
|
@@ -2383,16 +2383,16 @@ pathkeys_useful_for_ordering(PlannerInfo *root, List *pathkeys)
|
||||
* Count the number of pathkeys that are useful for grouping (instead of
|
||||
* explicit sort)
|
||||
*
|
||||
* Group pathkeys could be reordered to benefit from the odering. The ordering
|
||||
* may not be "complete" and may require incremental sort, but that's fine. So
|
||||
* we simply count prefix pathkeys with a matching group key, and stop once we
|
||||
* find the first pathkey without a match.
|
||||
* Group pathkeys could be reordered to benefit from the ordering. The
|
||||
* ordering may not be "complete" and may require incremental sort, but that's
|
||||
* fine. So we simply count prefix pathkeys with a matching group key, and
|
||||
* stop once we find the first pathkey without a match.
|
||||
*
|
||||
* So e.g. with pathkeys (a,b,c) and group keys (a,b,e) this determines (a,b)
|
||||
* pathkeys are useful for grouping, and we might do incremental sort to get
|
||||
* path ordered by (a,b,e).
|
||||
*
|
||||
* This logic is necessary to retain paths with ordeding not matching grouping
|
||||
* This logic is necessary to retain paths with ordering not matching grouping
|
||||
* keys directly, without the reordering.
|
||||
*
|
||||
* Returns the length of pathkey prefix with matching group keys.
|
||||
|
Reference in New Issue
Block a user