> * mtup is hold in hjstate->hj_outerTupleBuffer, so we can using
> * shouldFree as false to call ExecForceStoreMinimalTuple().
> *
> * When slot is TTSOpsMinimalTuple we can avoid realloc memory for
> * new MinimalTuple(reuse StringInfo to call ExecHashJoinGetSavedTuple).
>
> But my point
> 0) The patch does not apply anymore, thanks to David committing a patch> yesterday. Attached is a patch rebased on top of current master.That patch is based on PG17. I have now rewritten it based on the master branch and added some comments.> 1) Wouldn't it be easier (and just as efficient) to us
Avoid unnecessary form and deform tuple.
In the TPCH test, HashJoin speed up to ~2x.
diff --git a/src/backend/executor/nodeHash.c b/src/backend/executor/nodeHash.c
index 61480733a1..2dad0c8a55 100644
--- a/src/backend/executor/nodeHash.c
+++ b/src/backend/executor/nodeHash.c
@@ -1627,6 +1627,23 @
> We try fairly hard to ensure that the row count estimate for a given relation
> does not vary across paths, so I concur with the OP that this is a bug.
> Having
> said that, I'm not sure that the consequences are significant. As you say,
> the
> estimates seem to get a lot closer as soon as t
Normal aggregate and partition wise aggregate have a big difference rows cost:
begin;
create table t1(id integer, name text) partition by hash(id);
create table t1_0 partition of t1 for values with(modulus 3, remainder 0);
create table t1_1 partition of t1 for values with(modulus 3, remainder 1);
> > > Suppose parallelism is not in use and that param_info is NULL. Then,
> > > is path->subpath->rows guaranteed to be equal to baserel->rows? If
> > > yes, then we don't need to a three-part if statement as you propose
> > > here and can just change the "else" clause to say path->path.rows =
> >
