Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v39qw-00CVcT-CO for pgadmin-hackers@arkaria.postgresql.org; Mon, 29 Sep 2025 09:07:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1v39qu-0006Le-C2 for pgadmin-hackers@arkaria.postgresql.org; Mon, 29 Sep 2025 09:07:25 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v39qu-0006LW-3r for pgadmin-hackers@lists.postgresql.org; Mon, 29 Sep 2025 09:07:24 +0000 Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v39qq-000gPK-1K for pgadmin-hackers@postgresql.org; Mon, 29 Sep 2025 09:07:22 +0000 Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-57933d3e498so5225345e87.3 for ; Mon, 29 Sep 2025 02:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; t=1759136839; x=1759741639; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=637xKYG5sqAKk18CJ8cn9ck6SwuXWhHRJjJboMT9Mw8=; b=iMX1p02WxG53U2l50KkHGi3Zun0FtGKbKGDmbeXbuKxdGMjQbUvPnOxj8CcA2bDeYw g+GALEm0KRdtlkkJf9Fuxd3kBAa+uMdwh+C4b5MX0f0/Bs6wVAr4TTtQX1a3xfTrnx26 0A22PYLu/+gEAikKH5z13bH5Uk+74AXbvBxoK0bnjBl6rj+aPqCj49gX75ASTxG14fKh 09cMeTWOD7RfcCdvBxVvTrMzJKm2iin1gXxyz+jcI8F1LyeEdSxGljDhfGP9CIA5MLNZ fbW8pNA1JyC4B6vJrFhg/D3TAZCEE26uz5aH864/H9KJY9tgyo7owuhw/6kpgtiyW4Bf 9T9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759136839; x=1759741639; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=637xKYG5sqAKk18CJ8cn9ck6SwuXWhHRJjJboMT9Mw8=; b=qm28IIdK9O9RzVx2uWbEfcMuUMt9C+Ok0GPor6CivLVmFG0kCiiGfQOrU0C5fsSnhf eZB/xHXdl3QuxW8PX0TcwJkkWX2dH+s/pQKcZQvPi44pDPHxocvnlbiQ/iCzYSmDfX3Q bAxUhdJE0TnNfGlwL0pfkicO7QKZ9O83G5aDPJApnRsHxx+fzshlNJNNOClPXWejjN1d XetAlf5sg3xlogP2mETSVBrtktED+VKZ9ZQQbWk8BoaXMS0ZkdhEFeNKlJKbi0c6Fo+u sP/X2EKEJ5XoJu+MEQyh8SekNdER21hRhAq3xFeQWw7Wpu1jD+qcMXagScCPjpD97DJC eHUg== X-Gm-Message-State: AOJu0YzHDRd7Sx8ROduiMkMLg6fI/yulqVsWNgsi/k7KMBoiIpjOZdc3 zGtOTCcg2EhM6PzZQhD9bikHDCoZ1zUILASqHn8qUsdy5wgiEFlQHgS0SkrQjKqbjHAgncBdJAu /qYn7YrbNNQZLHkeBYe4YxuLp3xiWcaYAjuMT9eYo X-Gm-Gg: ASbGncugkrDq83Ss84RhRjJNQ2yuNPL9yTq9x0P6ZXvbPAwRRqHvyV5PKv9wkLbB4Wg 5hhVlqlqLT26JPoWB8lEyKnGV5zwyU5q7wq9zz/ohqaDXtOZz+uvML/LVVkpWzeZfDOH/kA7Vs5 LqnXleebHpFDaif1n/Tni8O4gggSD2GtvbvwhJ09/3lBU3hIA55IwOskPvbQ0nHTwAh6ZBWvKnO 1zwvm6JcXRq9DOA/Lqr X-Google-Smtp-Source: AGHT+IEBK2gfF6q2Cpc2LZAWl8Nno5WNofRzpG7yS2YQBuZ2SfBmL0u8X8qaFuU3weGpQ5vRkYyNkzLAYzrpYDMRZIM= X-Received: by 2002:a05:6512:3356:b0:57a:b1cb:82c5 with SMTP id 2adb3069b0e04-582d2b4a888mr4082744e87.38.1759136838678; Mon, 29 Sep 2025 02:07:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Mon, 29 Sep 2025 10:07:07 +0100 X-Gm-Features: AS18NWAJCaNkJkiJGzhIfy-k830nU8PxWwpmTSTYkYQVSqzr_SrC-PlPcrp0QZs Message-ID: Subject: Re: Regarding multiple result set in query tool To: Aditya Toshniwal Cc: pgadmin-hackers Content-Type: multipart/alternative; boundary="00000000000061926d063fecf6b0" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000061926d063fecf6b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 29 Sept 2025 at 10:01, Aditya Toshniwal < aditya.toshniwal@enterprisedb.com> wrote: > Hi, > > I raised this to the psycopg team and we may possibly not need to take > care of anything on the pgAdmin side. Check the discussion here - > https://github.com/psycopg/psycopg/discussions/1170 > Well that seems ideal - and Daniele seems quite open to the idea which is good news :-) > > But, I will have to raise a PR to get some extra functions for our > use-case. > > On Mon, Sep 29, 2025 at 11:23=E2=80=AFAM Aditya Toshniwal < > aditya.toshniwal@enterprisedb.com> wrote: > >> Hi Dave, >> >> On Thu, Sep 25, 2025 at 7:55=E2=80=AFPM Dave Page wr= ote: >> >>> >>> >>> 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 go= ing 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 nu= mber >>>> of columns and data. If we have a predefined algorithm which will deci= de >>>> 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 depe= nd >>> on the schema and data). The former is clearly easier to tune - it coul= d be >>> an arbitrary limit in the config, or it could be computed based on mach= ine >>> resources and utilisation, whilst the latter is always going to be a gu= ess. >>> I'm not sure I see another way. Anyone else? >>> >> For the first approach - python provides a function which we can use. Bu= t >> deciding the limit is something tricky. A user may still get out of memo= ry >> error with a limit set. It will all depend on what is running on his >> system. Setting the limit itself is like playing a video game. For the r= ow >> count based limit, we already have a per page limit - and adding more su= ch >> configs will only add more confusion. >> >> import sys >> >> my_tuple =3D (1, 2, 'hello', 4.5) >> memory_size =3D sys.getsizeof(my_tuple) >> print(f"The memory size of the tuple is: {memory_size} bytes") >> >> >>> -- >>> Dave Page >>> pgAdmin: https://www.pgadmin.org >>> PostgreSQL: https://www.postgresql.org >>> pgEdge: https://www.pgedge.com >>> >>> >> >> -- >> Thanks, >> Aditya Toshniwal >> pgAdmin Hacker | Sr. Staff SDE II | *enterprisedb.com* >> >> "Don't Complain about Heat, Plant a TREE" >> > > > -- > Thanks, > Aditya Toshniwal > pgAdmin Hacker | Sr. Staff SDE II | *enterprisedb.com* > > "Don't Complain about Heat, Plant a TREE" > --=20 Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com --00000000000061926d063fecf6b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, 29 Sept= 2025 at 10:01, Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:
Hi,

I raised=C2=A0this to the psycopg te= am and we may possibly not need to take care of anything on the pgAdmin sid= e. Check the discussion here -=C2=A0https://github.com/psycopg/psyco= pg/discussions/1170

Well th= at seems ideal - and Daniele seems quite open to the idea which is good new= s :-)
=C2=A0

But, I will have to raise a PR to get some extra functions fo= r our use-case.

On Mon, Sep 29, 2025 at 11:23=E2=80=AFAM Aditya Toshni= wal <aditya.toshniwal@enterprisedb.com> wrote:
Hi=C2=A0Dave,

On Thu, Sep 25, 2025 at 7:55=E2=80=AFPM Dave = Page <dpage@pgadm= in.org> wrote:


On Thu, 25 Sept 2025 at 14:44, Aditya Toshniwal <aditya.toshniw= al@enterprisedb.com> wrote:
Hi=C2=A0D= ave,

If pgAdmin were a single-u= ser application, I'd agree - however it is not when running in server m= ode. 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, excep= t where it clearly doesn't make sense.
=C2=A0
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=C2=A0decide the limits in a performa= nt 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 o= n 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?
For the first approach - python provides a function which we can use.= But deciding the limit is something tricky. A user may still get out of me= mory error with a limit set. It will all depend on what is running on his s= ystem. Setting the limit itself is like playing a video game. For the row c= ount based limit, we already have a per page limit - and adding more such c= onfigs will only add more confusion.

import sys

my_tuple =3D (1, 2, 'hello', 4.= 5)
memory_size =3D sys.getsizeof(my_tuple)
print(f"The memory size of the tuple is: {memory_size} byte= s")=C2=A0



--
Thanks,
Aditya Toshniw= al
pgAdmin Hacker=C2=A0| Sr. Staff SDE II=C2= =A0| enterprisedb.com
"Don't Complain about Heat, Plant a TREE"


--
Thanks,
Aditya Toshniw= al
pgAdmin Hacker=C2=A0| Sr. Staff SDE II=C2= =A0| enterprisedb.com
"Don't Complain about Heat, Plant a TREE"


--
--00000000000061926d063fecf6b0--