genericcostestimate() estimates the number of index leaf pages to
be visited as a pro-rata fraction of the total number of leaf pages.
Or at least that was the intention. What it actually used in the
calculation was the total number of index pages, so that non-leaf
pages were also counted. In a decent-sized index the error is
probably small, since we expect upper page fanout to be high.
But in a small index that's not true; in the worst case with one
data-bearing page plus a metapage, we had 100% relative error.
This led to surprising planning choices such as not using a small
partial index.
To fix, ask genericcostestimate's caller to supply an estimate of
the number of non-leaf pages, and subtract that. For the built-in
index AMs, it seems sufficient to count the index metapage (if the
AM uses one) as non-leaf. Per the above argument, counting upper
index pages shouldn't change the estimate much, and in most cases
we don't have any easy way of estimating the number of upper pages.
This might be an area for further research in future.
Any external genericcostestimate callers that do not set the new field
GenericCosts.numNonLeafPages will see the same behavior as before,
assuming they followed the advice to zero out that whole struct.
Unsurprisingly, this change affects a number of plans seen in the
core regression tests. I hacked up the existing tests to keep the
tests' plans the same, since in each case it appeared that the
test's intent was to test exactly that plan. Also add one new
test case demonstrating that a better index choice is now made.
Author: Tom Lane <tgl@sss.pgh.pa.us>
Reviewed-by: Henson Choi <assam258@gmail.com>
Discussion: https://postgr.es/m/870521.
1745860752@sss.pgh.pa.us
/* We have to visit all index tuples anyway */
costs.numIndexTuples = index->tuples;
+ /* As in btcostestimate, count only the metapage as non-leaf */
+ costs.numNonLeafPages = 1;
+
/* Use generic estimate */
genericcostestimate(root, path, loop_count, &costs);
return qual_arg_cost;
}
+/*
+ * Compute generic index access cost estimates.
+ *
+ * See struct GenericCosts in selfuncs.h for more info.
+ */
void
genericcostestimate(PlannerInfo *root,
IndexPath *path,
* Estimate the number of index pages that will be retrieved.
*
* We use the simplistic method of taking a pro-rata fraction of the total
- * number of index pages. In effect, this counts only leaf pages and not
- * any overhead such as index metapage or upper tree levels.
+ * number of index leaf pages. We disregard any overhead such as index
+ * metapages or upper tree levels.
*
* In practice access to upper index levels is often nearly free because
* those tend to stay in cache under load; moreover, the cost involved is
* highly dependent on index type. We therefore ignore such costs here
* and leave it to the caller to add a suitable charge if needed.
*/
- if (index->pages > 1 && index->tuples > 1)
- numIndexPages = ceil(numIndexTuples * index->pages / index->tuples);
+ if (index->pages > costs->numNonLeafPages && index->tuples > 1)
+ numIndexPages =
+ ceil(numIndexTuples * (index->pages - costs->numNonLeafPages)
+ / index->tuples);
else
numIndexPages = 1.0;
/*
* Now do generic index cost estimation.
+ *
+ * While we expended effort to make realistic estimates of numIndexTuples
+ * and num_sa_scans, we are content to count only the btree metapage as
+ * non-leaf. btree fanout is typically high enough that upper pages are
+ * few relative to leaf pages, so accounting for them would move the
+ * estimates at most a percent or two. Given the uncertainty in just how
+ * many upper pages exist in a particular index, we'll skip trying to
+ * handle that.
*/
costs.numIndexTuples = numIndexTuples;
costs.num_sa_scans = num_sa_scans;
+ costs.numNonLeafPages = 1;
genericcostestimate(root, path, loop_count, &costs);
{
GenericCosts costs = {0};
+ /* As in btcostestimate, count only the metapage as non-leaf */
+ costs.numNonLeafPages = 1;
+
genericcostestimate(root, path, loop_count, &costs);
/*
GenericCosts costs = {0};
Cost descentCost;
+ /* GiST has no metapage, so we treat all pages as leaf pages */
+
genericcostestimate(root, path, loop_count, &costs);
/*
GenericCosts costs = {0};
Cost descentCost;
+ /* As in btcostestimate, count only the metapage as non-leaf */
+ costs.numNonLeafPages = 1;
+
genericcostestimate(root, path, loop_count, &costs);
/*
* Similarly, they can set num_sa_scans to some value >= 1 for an index AM
* that doesn't necessarily perform exactly one primitive index scan per
* distinct combination of ScalarArrayOp array elements.
+ * Similarly, they can set numNonLeafPages to some value >= 1 if they know
+ * how many index pages are not leaf pages. (It's always good to count
+ * totally non-data-bearing pages such as metapages here, since accounting
+ * for the metapage can move cost estimates for a small index significantly.
+ * But upper pages in large indexes may be few enough relative to leaf pages
+ * that it's not worth trying to count them.)
*/
typedef struct
{
double numIndexTuples; /* number of leaf tuples visited */
double spc_random_page_cost; /* relevant random_page_cost value */
double num_sa_scans; /* # indexscans from ScalarArrayOpExprs */
+ BlockNumber numNonLeafPages; /* # of index pages that are not leaves */
} GenericCosts;
/* Hooks for plugins to get control when we ask for stats */
set enable_nestloop to 0;
set enable_hashjoin to 0;
set enable_sort to 0;
+-- we need additional data to get the partial indexes to be preferred
+insert into j1 select 2, i from generate_series(1, 100) i;
+insert into j2 select 1, i from generate_series(2, 100) i;
+analyze j1;
+analyze j2;
-- create indexes that will be preferred over the PKs to perform the join
create index j1_id1_idx on j1 (id1) where id1 % 1000 = 1;
create index j2_id1_idx on j2 (id1) where id1 % 1000 = 1;
--- need an additional row in j2, if we want j2_id1_idx to be preferred
-insert into j2 values(1,2);
-analyze j2;
explain (costs off) select * from j1
inner join j2 on j1.id1 = j2.id1 and j1.id2 = j2.id2
where j1.id1 % 1000 = 1 and j2.id1 % 1000 = 1;
INSERT INTO flt VALUES('-0.0'::float),('+0.0'::float);
ANALYZE flt;
SET enable_seqscan TO off;
+SET enable_material TO off;
-- Ensure memoize operates in logical mode
SELECT explain_memoize('
SELECT * FROM flt f1 INNER JOIN flt f2 ON f1.f = f2.f;', false);
(1 row)
RESET enable_seqscan;
+RESET enable_material;
RESET enable_mergejoin;
RESET work_mem;
RESET hash_mem_multiplier;
11
(1 row)
-RESET enable_indexscan;
-- check multi-index cases too
explain (costs off)
select unique1, unique2 from onek2
0 | 998
(2 rows)
+RESET enable_indexscan;
+-- onek2_u2_prtl should be preferred over this index, but we have to
+-- discount the metapage to arrive at that answer
+begin;
+create index onek2_index_full on onek2 (stringu1, unique2);
+explain (costs off)
+select unique2 from onek2
+ where stringu1 < 'B'::name;
+ QUERY PLAN
+----------------------------------------------
+ Index Only Scan using onek2_u2_prtl on onek2
+(1 row)
+
+rollback;
--
-- Test some corner cases that have been known to confuse the planner
--
set enable_hashjoin to 0;
set enable_sort to 0;
+-- we need additional data to get the partial indexes to be preferred
+insert into j1 select 2, i from generate_series(1, 100) i;
+insert into j2 select 1, i from generate_series(2, 100) i;
+analyze j1;
+analyze j2;
+
-- create indexes that will be preferred over the PKs to perform the join
create index j1_id1_idx on j1 (id1) where id1 % 1000 = 1;
create index j2_id1_idx on j2 (id1) where id1 % 1000 = 1;
--- need an additional row in j2, if we want j2_id1_idx to be preferred
-insert into j2 values(1,2);
-analyze j2;
-
explain (costs off) select * from j1
inner join j2 on j1.id1 = j2.id1 and j1.id2 = j2.id2
where j1.id1 % 1000 = 1 and j2.id1 % 1000 = 1;
ANALYZE flt;
SET enable_seqscan TO off;
+SET enable_material TO off;
-- Ensure memoize operates in logical mode
SELECT explain_memoize('
WHERE t0.ten = t1.twenty AND t0.two <> t2.four OFFSET 0);
RESET enable_seqscan;
+RESET enable_material;
RESET enable_mergejoin;
RESET work_mem;
RESET hash_mem_multiplier;
explain (costs off)
select unique2 from onek2 where unique2 = 11 and stringu1 < 'B';
select unique2 from onek2 where unique2 = 11 and stringu1 < 'B';
-RESET enable_indexscan;
-- check multi-index cases too
explain (costs off)
select unique1, unique2 from onek2
where (unique2 = 11 and stringu1 < 'B') or unique1 = 0;
select unique1, unique2 from onek2
where (unique2 = 11 and stringu1 < 'B') or unique1 = 0;
+RESET enable_indexscan;
+
+-- onek2_u2_prtl should be preferred over this index, but we have to
+-- discount the metapage to arrive at that answer
+begin;
+create index onek2_index_full on onek2 (stringu1, unique2);
+explain (costs off)
+select unique2 from onek2
+ where stringu1 < 'B'::name;
+rollback;
--
-- Test some corner cases that have been known to confuse the planner
projects / thirdparty / postgresql.git / commitdiff
