MIME-Version: 1.0
References: <CAG4Txrii4-gTMpGEKLzCSe14svoJGgrh2AY=3LAgmqN2Um=o4A@mail.gmail.com>
In-Reply-To: <CAG4Txrii4-gTMpGEKLzCSe14svoJGgrh2AY=3LAgmqN2Um=o4A@mail.gmail.com>
From: Greg Sabino Mullane <htamfids@gmail.com>
Date: Mon, 3 Jun 2024 09:12:13 -0400
Message-ID: <CAKAnmm+4RLHrKSyedZ+hTkwedP05+Ldp+bHiD00SuJvgAekRgA@mail.gmail.com>
Subject: Re: Postgresql 16.3 Out Of Memory
To: Radu Radutiu <rradutiu@gmail.com>
Cc: pgsql-general <pgsql-general@postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000002686290619fc17c1"
Archived-At: <https://www.postgresql.org/message-id/CAKAnmm%2B4RLHrKSyedZ%2BhTkwedP05%2BLdp%2BbHiD00SuJvgAekRgA%40mail.gmail.com>
Precedence: bulk

--0000000000002686290619fc17c1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 3, 2024 at 6:19=E2=80=AFAM Radu Radutiu <rradutiu@gmail.com> wr=
ote:

> Do you have any idea how to further debug the problem?
>

Putting aside the issue of non-reclaimed memory for now, can you show us
the actual query? The explain analyze you provided shows it doing an awful
lot of joins and then returning 14+ million rows to the client. Surely the
client does not need that many rows?

You can probably also prevent OOM by lowering your work_mem and/or your
max_parallel_workers_per_gather.

Cheers,
Greg

--0000000000002686290619fc17c1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Jun 3, 2024 at 6:19=E2=80=AFAM Ra=
du Radutiu &lt;<a href=3D"mailto:rradutiu@gmail.com">rradutiu@gmail.com</a>=
&gt; wrote:=C2=A0<br></div><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Do you have any idea how=
 to further debug the problem?=C2=A0</div></div></blockquote><div><br></div=
><div>Putting aside the issue of non-reclaimed memory for now, can you show=
 us the actual query? The explain analyze you provided shows it doing an aw=
ful lot of joins and then returning 14+ million rows to the client. Surely =
the client does not need that many rows?</div><div><br></div><div>You can p=
robably also prevent OOM by lowering your work_mem and/or your max_parallel=
_workers_per_gather.</div><div><br></div><div>Cheers,</div><div>Greg</div><=
div><br></div></div></div>

--0000000000002686290619fc17c1--