diff options
Diffstat (limited to 'src/backend/optimizer')
| -rw-r--r-- | src/backend/optimizer/path/costsize.c | 6 | ||||
| -rw-r--r-- | src/backend/optimizer/path/pathkeys.c | 10 |
2 files changed, 8 insertions, 8 deletions
diff --git a/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c index ec3c23013a3..b787c6f81a8 100644 --- a/src/backend/optimizer/path/costsize.c +++ b/src/backend/optimizer/path/costsize.c @@ -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 diff --git a/src/backend/optimizer/path/pathkeys.c b/src/backend/optimizer/path/pathkeys.c index 75fe03fd04b..91556910aec 100644 --- a/src/backend/optimizer/path/pathkeys.c +++ b/src/backend/optimizer/path/pathkeys.c @@ -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. |