a_ogawa <[EMAIL PROTECTED]> writes:
> In SQL that executes aggregation, AllocSetReset is called many times and
> spend a lot of cycles.
> This patch saves the cycles spent by AllocSetReset.
Hmm. It doesn't seem like this could be a big win overall. It's not
possible to save a whole lot of cycles inside AllocSetReset, because if
there isn't anything for it to do, it should fall through pretty quickly
anyway. And I'm worried about adding even a small amount of overhead to
palloc/pfree --- on the vast majority of the profiles I look at, those
are more expensive than AllocSetReset.
I duplicated your test case to see where the reset calls were coming
from, and got this:
0.00 0.00 25/17500065 agg_retrieve_hash_table [453]
0.29 0.10 2499975/17500065 execTuplesMatch [33]
0.29 0.10 2500000/17500065 agg_fill_hash_table <cycle 3>
[22]
0.29 0.10 2500000/17500065 ExecScanHashBucket [32]
0.29 0.10 2500025/17500065 ExecHashGetHashValue [53]
0.29 0.10 2500035/17500065 ExecScan [52]
0.58 0.20 5000005/17500065 ExecHashJoin <cycle 3> [15]
[30] 5.8 2.04 0.70 17500065 MemoryContextReset [30]
0.70 0.00 17500065/17500065 MemoryContextResetChildren
[56]
(Does this match your profile? I only ran the query 5 times not 10.)
This shows that the majority of the resets are coming from the hashjoin
code not the aggregation code. I wonder if we could reduce the number
of reset calls in that logic. I think I threw in a few extras in the
recent hashjoin revisions, feeling that they were cheap enough that I
didn't need to think too hard about whether any were unnecessary.
I think what you've really proven here is that that was a wrong guess
...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
