From: Tom Lane <tgl@sss.pgh.pa.us>
To: Davlet Panech <dpanech@gmail.com>
cc: pgsql-admin@lists.postgresql.org
Subject: Re: Abnormally high memory usage/OOM triggered
In-reply-to: <15a90b55-5151-ce22-16ee-7ff883e5eb97@gmail.com>
References: <4d52fee7-73ba-16a9-9c27-8ae5107ee6ae@gmail.com>
 <5E0AB8DB-F13B-41BF-843A-FE64FBE9C097@elevated-dev.com>
 <15a90b55-5151-ce22-16ee-7ff883e5eb97@gmail.com>
Comments: In-reply-to Davlet Panech <dpanech@gmail.com>
	message dated "Thu, 18 Jan 2018 12:13:33 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7975.1516297077.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 18 Jan 2018 12:37:57 -0500
Message-ID: <7976.1516297077@sss.pgh.pa.us>
Precedence: bulk

Davlet Panech <dpanech@gmail.com> writes:
> On 1/17/2018 5:57 PM, scott ribe wrote:
>> It does seem awfully high, but... An update can involve a join across m=
ultiple tables. Or an update can run a trigger which can cascade. Either o=
f those could result in an "accidental cross product" join, which can alwa=
ys blow up memory.


> There must be a way to put an upper limit on memory even for such cases.=
 =

> I was under the impression that parameters such as "work_mem" serve that=
 =

> purpose, is that not the case? So an "accidental cross product" join's =

> memory usage is unbounded? It can't be... could somebody confirm this =

> please?

A large join result could blow out memory on the client side, unless the
client is careful to read it in segments, which most clients aren't.
I expect the server to be smarter though.

			regards, tom lane