I wrote:
> Yeah, I wouldn't sweat over the specific value. The pre-v13 behavior
> was effectively equivalent to hash_mem_multiplier = infinity, so if
> you weren't having any OOM problems before, just crank it up.
Oh, wait, scratch that: the old executor's behavior is accurately
described by that
"l...@laurent-hasson.com" writes:
> One question that popped up in my head. hash_mem_multiplier is an upper-bound
> right: it doesn't reserve memory ahead of time correct? So there is no reason
> for me to spend undue amounts of time fine-tuning this parameter? If I have
> work_mem to 521MB, th
On Tue, Jul 27, 2021 at 7:57 PM l...@laurent-hasson.com <
l...@laurent-hasson.com> wrote:
> hash_mem_multiplier is an upper-bound right: it doesn't reserve memory
> ahead of time correct?
>
Yes, that is what the phrasing "maximum amount" in the docs is trying to
convey.
https://www.postgresql.or
Tom,
One question that popped up in my head. hash_mem_multiplier is an upper-bound
right: it doesn't reserve memory ahead of time correct? So there is no reason
for me to spend undue amounts of time fine-tuning this parameter? If I have
work_mem to 521MB, then I can set hash_mem_multiplier to 8
On Tue, Jul 27, 2021 at 09:08:49AM +, Simen Andreas Andreassen Lønsethagen
wrote:
> >Easy first question: is the temp table analyzed before being used in a
> > join ?
>
> No, I haven't done that. Today, I tried to run
>
> ANALYZE records_to_filter_on;
>
> on the same sample data
On Tue, Jul 27, 2021 at 10:44:03PM +0530, kenny a wrote:
> Hi Experts,
>
> The attached query is performing slow, this needs to be optimized to
> improve the performance.
>
> Could you help me with query rewrite (or) on new indexes to be created to
> improve the performance?
>
>
> Hi Experts,
>
> The attached query is performing slow, this needs to be optimized to
> improve the performance.
>
> Could you help me with query rewrite (or) on new indexes to be created to
> improve the performance?
>
> Thanks a ton in advance for your support.
>
