| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Craig Milhiser <craig(at)milhiser(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Reference to - BUG #18349: ERROR: invalid DSA memory alloc request size 1811939328, CONTEXT: parallel worker |
| Date: | 2024-10-14 06:26:09 |
| Message-ID: | 3581840.1728887169@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Andrei Lepikhov <lepihov(at)gmail(dot)com> writes:
> My explanation (correct if I'm wrong):
> OUTER JOINs allow NULLs to be in a hash table. At the same time, a hash
> value for NULL is 0, and it goes to the batch==0.
> If batch number 0 gets overfilled, the
> ExecParallelHashIncreaseNumBatches routine attempts to increase the
> number of batches - but nothing happens. The initial batch is still too
> big, and the number of batches doubles up to the limit.
Interesting point. If memory serves (I'm too tired to actually look)
the planner considers the statistical most-common-value when
estimating whether an unsplittable hash bucket is likely to be too
big. It does *not* think about null values ... but it ought to.
However, this does not explain why PHJ would be more subject to
the problem than non-parallel HJ.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ba Jinsheng | 2024-10-14 06:52:30 | Re: Question of Parallel Hash Join on TPC-H Benchmark |
| Previous Message | Amit Kapila | 2024-10-14 06:25:34 | Re: BUG #18644: ALTER PUBLICATION ... SET (publish_via_partition_root) wrong/undocumented behavior. |