mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fix cost_rescan() to account for multi-batch hashing correctly.

Browse Source 
cost_rescan assumed that we don't need to rebuild the hash table when
rescanning a hash join.  However, that's currently only true for
single-batch joins; for a multi-batch join we must charge full freight.

This probably has escaped notice because we'd be unlikely to put a hash
join on the inside of a nestloop anyway.  Nonetheless, it's wrong.
Fix in HEAD, but don't backpatch for fear of destabilizing plans in
stable releases.
This commit is contained in:
Tom Lane 2016-07-27 17:44:34 -04:00
parent b31875b1fe
commit 69995c3b3f
1 changed files with 14 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
src/backend/optimizer/path/costsize.c
View File

@ -3114,11 +3114,21 @@ cost_rescan(PlannerInfo *root, Path *path,
case T_HashJoin: case T_HashJoin:
/* /*
* Assume that all of the startup cost represents hash table * If it's a single-batch join, we don't need to rebuild the hash
* building, which we won't have to do over. * table during a rescan.
*/ */
if (((HashPath *) path)->num_batches == 1)
{
/* Startup cost is exactly the cost of hash table building */
*rescan_startup_cost = 0; *rescan_startup_cost = 0;
*rescan_total_cost = path->total_cost - path->startup_cost; *rescan_total_cost = path->total_cost - path->startup_cost;
}
else
{
/* Otherwise, no special treatment */
*rescan_startup_cost = path->startup_cost;
*rescan_total_cost = path->total_cost;
}
break; break;
case T_CteScan: case T_CteScan:
case T_WorkTableScan: case T_WorkTableScan: