From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Frits Jalvingh <jal(at)etc(dot)to> |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15225: [XX000] ERROR: invalid DSA memory alloc request size 1073741824 / Where: parallel worker |
Date: | 2018-06-06 14:38:13 |
Message-ID: | 6681.1528295893@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Frits Jalvingh <jal(at)etc(dot)to> writes:
> As far as that explain thing goes, the odd thing seems to be that /without/
> the explain the database uses a non parallel plan. If I execute the exact
> same statement without explain I see one postgres process running at 100%
> for a long time, then it produces its output proper.
This doesn't prove that the thing is non-parallel, only that the work is
badly distributed. You might try cranking up log_min_messages to the
point that worker-process launching gets logged, and then see whether
or not it's really non-parallel.
> - explain seems to somehow influence the plan that is being made.
That should absolutely *not* be the case.
> - there is a big problem with postgres memory assignment, because with the
> increase of parallelism having work_mem work per process means that you
> cannot effectively control the amount of memory that postgres uses anymore.
work_mem has always been like that. You cannot set it to any very large
fraction of your system's available memory, at least not globally across
a whole bunch of queries.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-06-06 14:48:09 | Re: psql crashes found when executing slash commands |
Previous Message | Frits Jalvingh | 2018-06-06 10:15:25 | Re: BUG #15225: [XX000] ERROR: invalid DSA memory alloc request size 1073741824 / Where: parallel worker |