On Fri, Aug 23, 2024 at 08:17:26AM -0400, Robert Haas wrote:
> On Fri, Aug 23, 2024 at 7:02 AM bucoo wrote:
> > Howerver, the non-parallel hashjoin indeed showed about a 10% performance
> > improvement.
> >-> Hash Join (cost=508496.00..2302429.31 rows=47989008 width=0)
> > (actual time=107
On Fri, Aug 23, 2024 at 7:02 AM bucoo wrote:
> Howerver, the non-parallel hashjoin indeed showed about a 10% performance
> improvement.
>-> Hash Join (cost=508496.00..2302429.31 rows=47989008 width=0) (actual
> time=1075.213..9503.727 rows=47989007 loops=1)
>-> Hash Join (cost=508496
> * 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
Hi,
It seems you responded by writing a new message and just copying the
subject, which unfortunately doesn't set the headers used for threading
(e.g. in archives). Please just respond to the message.
Or maybe your client does not set the References/In-Reply-To headers
correctly. Not sure which m
On Thu, 22 Aug 2024 at 17:08, bucoo wrote:
>
> > 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 comm
cached in memory),not full query, include non-parallel HashJoin.non-parallel HashJoin only when batchs large then one will speed up,because this patch only optimize for read batchs tuples to memory.
optimize-hashjoin-master.patch
Description: Binary data
On Aug 21, 2024 19:17, Robert Haas wrote:On Wed, Aug 21, 2024 at 12:31 PM Tomas Vondra wrote:
> Anyway, I took a look and the basic idea is simple - when shuffling
> tuples between batches in a hash join, we're currently deforming the
> tuple (->slot) we just read from a batch, only to immedia
On Wed, Aug 21, 2024 at 12:31 PM Tomas Vondra wrote:
> Anyway, I took a look and the basic idea is simple - when shuffling
> tuples between batches in a hash join, we're currently deforming the
> tuple (->slot) we just read from a batch, only to immediately form it
> (slot->) again and write it to
Hi,
On 8/21/24 03:49, bucoo wrote:
> Avoid unnecessary form and deform tuple.
>
Thanks for the patch. Generally speaking, it's usually a good idea to
briefly explain what the patch does, why is that beneficial, in what
circumstances, etc. It's sometimes not quite obvious from the patch
itself (e
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 @
10 matches
Mail list logo
