MIME-Version: 1.0
References: 
 <CAM9w-_mQsC--AfLuEbv0NbW_p_b=PTD0ZbQr8J2Vv=2ioDp_gw@mail.gmail.com>
 <CA+OCxowcJNADQdbrzX9qxtOt+8qAS36tcYyE=-tcdQFWGqzVQw@mail.gmail.com>
 <CAM9w-_mbXuLXhJKB7KMBvqsCLeKkC2ubcAcxuVq7KR8DzqB_zA@mail.gmail.com>
 <CA+OCxozF-kD5=AsuaX10_Kh1sBpM3stSsPC7-RGLYpx=a_ahJQ@mail.gmail.com>
 <CAM9w-_mSHJuKE1HJceDOQqxZe1Yq4DaYG6fxMeAooY=8xBvgGA@mail.gmail.com>
 <CA+OCxoyO2FNEqa1aw8Czvpjv15qiN5Uk17Sbwc1+2t4B-JTsZA@mail.gmail.com>
 <CAM9w-_koTeoUazBctc=cTTEn3HeRE2gYNETNGtJp3ZTr3gLdSw@mail.gmail.com>
In-Reply-To: 
 <CAM9w-_koTeoUazBctc=cTTEn3HeRE2gYNETNGtJp3ZTr3gLdSw@mail.gmail.com>
From: Dave Page <dpage@pgadmin.org>
Date: Thu, 25 Sep 2025 15:25:26 +0100
Message-ID: 
 <CA+OCxoybXgPbEAK+xdHQyAeFPmwXU+Tb4h0ZNHRPLVvTdtcDBw@mail.gmail.com>
Subject: Re: Regarding multiple result set in query tool
To: Aditya Toshniwal <aditya.toshniwal@enterprisedb.com>
Cc: pgadmin-hackers <pgadmin-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000735131063fa0f107"
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BOCxoybXgPbEAK%2BxdHQyAeFPmwXU%2BTb4h0ZNHRPLVvTdtcDBw%40mail.gmail.com>
Precedence: bulk

--000000000000735131063fa0f107
Content-Type: text/plain; charset="UTF-8"

On Thu, 25 Sept 2025 at 14:44, Aditya Toshniwal <
aditya.toshniwal@enterprisedb.com> wrote:

> Hi Dave,
>
>>
>> If pgAdmin were a single-user application, I'd agree - however it is not
>> when running in server mode. Other users will not know what is going on if
>> one user exhausts memory.
>>
> How about allowing multi result sets only for desktop app?
>

I *really* dislike that. We should support all features in both modes,
except where it clearly doesn't make sense.


> The problem with memory limits is - it's an extra overhead to keep
> checking how much memory is consumed. A row size will depend on the number
> of columns and data. If we have a predefined algorithm which will decide
> the limits in a performant way is desirable.
>

Well we can take the extra cycles to compute actual memory usage, or we can
just pick an arbitrary number of rows (which as you note, will depend on
the schema and data). The former is clearly easier to tune - it could be an
arbitrary limit in the config, or it could be computed based on machine
resources and utilisation, whilst the latter is always going to be a guess.
I'm not sure I see another way. Anyone else?

-- 
Dave Page
pgAdmin: https://www.pgadmin.org
PostgreSQL: https://www.postgresql.org
pgEdge: https://www.pgedge.com

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

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, 25 Sept=
 2025 at 14:44, Aditya Toshniwal &lt;<a href=3D"mailto:aditya.toshniwal@ent=
erprisedb.com">aditya.toshniwal@enterprisedb.com</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div style=3D"font-family:=
verdana,sans-serif">Hi=C2=A0Dave,</div></div><div class=3D"gmail_quote"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div><br></div><d=
iv>If pgAdmin were a single-user application, I&#39;d agree - however it is=
 not when running in server mode. Other users will not know what is going o=
n if one user exhausts memory.</div></div></div></blockquote><div><span cla=
ss=3D"gmail_default" style=3D"font-family:verdana,sans-serif">How about all=
owing multi result sets only for desktop app?</span></div></div></div></blo=
ckquote><div><br></div><div>I *really* dislike that. We should support all =
features in both modes, except where it clearly doesn&#39;t make sense.</di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color=
:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_qu=
ote"><div><span class=3D"gmail_default" style=3D"font-family:verdana,sans-s=
erif">The problem with memory limits is - it&#39;s an extra overhead to kee=
p checking how much memory is consumed. A row size will depend on the numbe=
r of columns and data. If we have a predefined algorithm which will=C2=A0de=
cide the limits in a performant way is desirable.</span></div></div></div><=
/blockquote><div><br></div><div>Well we can take the extra cycles to comput=
e actual memory usage, or we can just pick an arbitrary number of rows (whi=
ch as you note, will depend on the schema and data). The former is clearly =
easier to tune - it could be an arbitrary limit in the config, or it could =
be computed based on machine resources and utilisation, whilst the latter i=
s always going to be a guess. I&#39;m not sure I see another way. Anyone el=
se?</div></div><div><br></div><span class=3D"gmail_signature_prefix">-- </s=
pan><br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr">Dave Pa=
ge<div>pgAdmin: <a href=3D"https://www.pgadmin.org" target=3D"_blank">https=
://www.pgadmin.org</a></div><div>PostgreSQL: <a href=3D"https://www.postgre=
sql.org" target=3D"_blank">https://www.postgresql.org</a></div><div>pgEdge:=
 <a href=3D"https://www.pgedge.com" target=3D"_blank">https://www.pgedge.co=
m</a><br><div></div><div><br></div></div></div></div></div>

--000000000000735131063fa0f107--