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 1v39lm-00CTry-0G for pgadmin-hackers@arkaria.postgresql.org; Mon, 29 Sep 2025 09:02:06 +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 1v39li-0005es-Ve for pgadmin-hackers@arkaria.postgresql.org; Mon, 29 Sep 2025 09:02:03 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v39li-0005ek-KT for pgadmin-hackers@lists.postgresql.org; Mon, 29 Sep 2025 09:02:03 +0000 Received: from mail-vs1-xe33.google.com ([2607:f8b0:4864:20::e33]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v39lf-000Tgr-0Z for pgadmin-hackers@postgresql.org; Mon, 29 Sep 2025 09:02:01 +0000 Received: by mail-vs1-xe33.google.com with SMTP id ada2fe7eead31-5b658b006e2so1450260137.0 for ; Mon, 29 Sep 2025 02:01:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1759136518; x=1759741318; 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=iA0WrqSZl2gwZ0kKn0unx8Hn24Iy1oCgsojTvj+zkGM=; b=hjjn59ePVHkUE7MtYmAFF3Grs9RMttBVHU0VNbD1zo0FbSfcLm8Qzi3TEeA+PdlENE +pnN4r4EmkMnRHLGSbhY4e9CAIJ4iJvkEExgEkrxxoJDCC8gJwDBfaCmB/7F5M/7RNUS 6AJxJbH7n5n8+zPpQmJoKJ/c0lQl7SkXIOdVidQmjVf5gJP+rTyxtd4pyAdam0z+pj/5 lrPCu02tiLTCQAMQmALgV+pgUIaMrk4fJWtDtCr3O3EsEtQzGeX/X7cEqHYvTGho/Nz3 iG5zH/Bk/4SxWorF4hwdTqN0hOk06ObjTKPw/Q0motjZQKexicXZgcLM8GSnSYZGcycQ pHyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759136518; x=1759741318; 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=iA0WrqSZl2gwZ0kKn0unx8Hn24Iy1oCgsojTvj+zkGM=; b=vqkfNEw2dwidiyRGadzMxRMDnB2DCidbZKTCRBm4vcIOYigrZ+wKIgFI6alR8PABiZ O6y9MAQfO1L4UrvmunXrylFnWGopf6hQoRQUWoKMkokMfNoKrtwWzAJLMu6neGTcI2hj z8c0Z4UpEoXolE7HQyQaJX5sQR8Bo8rm27ZaIWckGkvtZAsEzslyCoIxQTcJk1s8sYDR Jxgry9zTqE9NsjLwE6A0lD83OKBEdrz0JnaV/cfjKuxw167s2GQiEZRrHEQQ/RvbLWdz +ZG+P8I6uaRH/2FGkdASr3tcSwY9PzADz0VxuSHFd+DA9GVFwmFHTskYChTWC+Shlc// avyQ== X-Gm-Message-State: AOJu0Ywz4We2I5MMhRK49JNQgM75q+E0CqNd5h6w6Sz1bdc4ScT8qW2H H2Ic7Y/yl5knRCeB78J0s3hE1T66VlBt+JIx16TAsZhp2ckOs5SdUxDAJ0j1ZDHjhdIEVPWrk/h DlDsi/DwTTd/znoei8Q/drD/EDRt6OGp+Y99iehb0 X-Gm-Gg: ASbGncsFvge31jbRWDACQQqhnNQXHjA6LGKOkXGuNXqoPK+0wgMCu3tbfOxU4uQsEZl HKO1nOTd8rZDOo2H/62XYUNC9tG2vKoIgKV18aaRC1jFg1galdYzvrh1dn70g1YjUsjzTBCQoI7 pxtsXSQ9EbmgyjnEPKRYjElmL7c/02Ze6Lf2Jsd/NXXNbdYliYfddN1y4f0NQrGKXt+ZjO1J+Iq dK1Qt8ESJ7XXrq5AyE= X-Google-Smtp-Source: AGHT+IEPAup05NgeALJLz0XE1Z+KQ9Yyt3bhyf+m/rgIugTlntCj4jmxrUyokRL/oZAHvTyv0oNmJuOMER4QqZgYu8o= X-Received: by 2002:a05:6102:b0c:b0:59d:c33d:2ffa with SMTP id ada2fe7eead31-5acd1c83640mr6132512137.35.1759136518369; Mon, 29 Sep 2025 02:01:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aditya Toshniwal Date: Mon, 29 Sep 2025 14:31:31 +0530 X-Gm-Features: AS18NWDRS8t1CAeYvsXnBEW1triZ9ULC0vBuqEeGgrwIzBzmLqSOX0JZenY1Slk Message-ID: Subject: Re: Regarding multiple result set in query tool To: Dave Page Cc: pgadmin-hackers Content-Type: multipart/alternative; boundary="0000000000004a083b063fece35a" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000004a083b063fece35a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 wro= te: > >> >> >> 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 goi= ng 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 num= ber >>> of columns and data. If we have a predefined algorithm which will decid= e >>> 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 depen= d >> 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 machi= ne >> resources and utilisation, whilst the latter is always going to be a gue= ss. >> 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 memor= y > 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 ro= w > count based limit, we already have a per page limit - and adding more suc= h > 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" > --=20 Thanks, Aditya Toshniwal pgAdmin Hacker | Sr. Staff SDE II | *enterprisedb.com* "Don't Complain about Heat, Plant a TREE" --0000000000004a083b063fece35a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I raised=C2=A0this to the psycopg team and we may poss= ibly not need to take care of anything on the pgAdmin side. Check the discu= ssion here -=C2=A0https://github.com/psycopg/psycopg/discussions/1170

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 Toshn= iwal <aditya.toshni= wal@enterprisedb.com> wrote:
Hi=C2=A0Dave,
<= br>
On Thu,= Sep 25, 2025 at 7:55=E2=80=AFPM Dave Page <dpage@pgadmin.org> wrote:


On Thu, 25 Sept 2025 at 14:44, Aditya Toshniwal <aditya.toshniwal@ent= erprisedb.com> wrote:
Hi=C2=A0Dave,

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

I *really* disli= ke that. We should support all features in both modes, except where it clea= rly doesn't make sense.
=C2=A0
<= span class=3D"gmail_default" style=3D"font-family:verdana,sans-serif">The p= roblem 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 column= s and data. If we have a predefined algorithm which will=C2=A0decide the li= mits in a performant way is desirable.

Well we can take the extra cycles to compute actual me= mory usage, or we can just pick an arbitrary number of rows (which as you n= ote, will depend on the schema and data). The former is clearly easier to t= une - 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 go= ing 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 s= till get out of memory error with a limit set. It will all depend on what i= s running on his system. Setting the limit itself is like playing a video g= ame. For the row count based limit, we already have a per page limit - and = adding more such configs will only add more confusion.

import sys

my_tuple =3D (1, 2, &= #39;hello', 4.5)
memory_size =3D sys.getsizeof(my_tuple)
<= div>print(f"The memory size of the tuple is: = {memory_size} bytes")=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"
--0000000000004a083b063fece35a--