summaryrefslogtreecommitdiff
path: root/src/include/access/nbtree.h
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2013-01-11 12:56:58 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2013-01-11 12:56:58 -0500
commit31f38f28b00cbe2b9267205359e3cf7bafa1cb97 (patch)
treed6220cc699b6e265924ba5546e1e0eb83ec287c3 /src/include/access/nbtree.h
parente1b735ae35f225927c95746babafaa84e39c3325 (diff)
downloadpostgresql-31f38f28b00cbe2b9267205359e3cf7bafa1cb97.tar.gz
Redesign the planner's handling of index-descent cost estimation.
Historically we've used a couple of very ad-hoc fudge factors to try to get the right results when indexes of different sizes would satisfy a query with the same number of index leaf tuples being visited. In commit 21a39de5809cd3050a37d2554323cc1d0cbeed9d I tweaked one of these fudge factors, with results that proved disastrous for larger indexes. Commit bf01e34b556ff37982ba2d882db424aa484c0d07 fudged it some more, but still with not a lot of principle behind it. What seems like a better way to address these issues is to explicitly model index-descent costs, since that's what's really at stake when considering diferent indexes with similar leaf-page-level costs. We tried that once long ago, and found that charging random_page_cost per page descended through was way too much, because upper btree levels tend to stay in cache in real-world workloads. However, there's still CPU costs to think about, and the previous fudge factors can be seen as a crude attempt to account for those costs. So this patch replaces those fudge factors with explicit charges for the number of tuple comparisons needed to descend the index tree, plus a small charge per page touched in the descent. The cost multipliers are chosen so that the resulting charges are in the vicinity of the historical (pre-9.2) fudge factors for indexes of up to about a million tuples, while not ballooning unreasonably beyond that, as the old fudge factor did (even more so in 9.2). To make this work accurately for btree indexes, add some code that allows extraction of the known root-page height from a btree. There's no equivalent number readily available for other index types, but we can use the log of the number of index pages as an approximate substitute. This seems like too much of a behavioral change to risk back-patching, but it should improve matters going forward. In 9.2 I'll just revert the fudge-factor change.
Diffstat (limited to 'src/include/access/nbtree.h')
-rw-r--r--src/include/access/nbtree.h1
1 files changed, 1 insertions, 0 deletions
diff --git a/src/include/access/nbtree.h b/src/include/access/nbtree.h
index eef67f54b5..0e35d7ad25 100644
--- a/src/include/access/nbtree.h
+++ b/src/include/access/nbtree.h
@@ -626,6 +626,7 @@ extern void _bt_insert_parent(Relation rel, Buffer buf, Buffer rbuf,
extern void _bt_initmetapage(Page page, BlockNumber rootbknum, uint32 level);
extern Buffer _bt_getroot(Relation rel, int access);
extern Buffer _bt_gettrueroot(Relation rel);
+extern int _bt_getrootheight(Relation rel);
extern void _bt_checkpage(Relation rel, Buffer buf);
extern Buffer _bt_getbuf(Relation rel, BlockNumber blkno, int access);
extern Buffer _bt_relandgetbuf(Relation rel, Buffer obuf,