| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Craig Milhiser <craig(at)milhiser(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-09-23 02:23:17 |
| Message-ID: | CA+hUKG+YZpOyP-XXT65o9hx=oGF+9-BJzjqzRXcdvWV=ZrJbTA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Mon, Sep 23, 2024 at 1:46 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> 432 bytes
Oh, as Tomas pointed out in the referenced thread, the actual number
depends on the number of workers because there is some per-worker
state for partitions, but that number does seem consistent with your
reported case. Perhaps the correct answer is simply to give up
partitioning when the partition state size would exceed the potential
hash table savings by further partitioning. Another question is
whether it's arriving at the problematic number by underestimating and
then repeatedly expanding, which is very inefficient, or planning the
high number from the outset, but either way that'd be two different
code paths that would need to respect a new cap. If it's the former,
there may also be ways to improve initial estimates with statistics.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Kostevych | 2024-09-23 04:39:20 | Can't fix Pgsql Insert Command Issue. |
| Previous Message | Thomas Munro | 2024-09-23 01:46:07 | Re: Reference to - BUG #18349: ERROR: invalid DSA memory alloc request size 1811939328, CONTEXT: parallel worker |