postgres.git / summary / log / commit / refs

commit    69995c3b3fd64361bb4d3938315f3e88ccc01e53
Author:   Tom Lane <tgl@sss.pgh.pa.us>
Date:     Wed Jul 27 21:44:34 2016 +0000
First released in: 9.6.0

    Fix cost_rescan() to account for multi-batch hashing correctly.
    
    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.


 src/backend/optimizer/path/costsize.c | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c
index 1c20edcdfeb..2a49639f125 100644
--- a/src/backend/optimizer/path/costsize.c
+++ b/src/backend/optimizer/path/costsize.c
@@ -3114,11 +3114,21 @@ cost_rescan(PlannerInfo *root, Path *path,
 		case T_HashJoin:
 
 			/*
-			 * Assume that all of the startup cost represents hash table
-			 * building, which we won't have to do over.
+			 * If it's a single-batch join, we don't need to rebuild the hash
+			 * table during a rescan.
 			 */
-			*rescan_startup_cost = 0;
-			*rescan_total_cost = path->total_cost - path->startup_cost;
+			if (((HashPath *) path)->num_batches == 1)
+			{
+				/* Startup cost is exactly the cost of hash table building */
+				*rescan_startup_cost = 0;
+				*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;
 		case T_CteScan:
 		case T_WorkTableScan:


[parent: b31875b1fe71]