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 1sOCUx-00CyRh-RZ for pgadmin-support@arkaria.postgresql.org; Mon, 01 Jul 2024 08:34:56 +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 1sOCUw-00H2rr-3e for pgadmin-support@arkaria.postgresql.org; Mon, 01 Jul 2024 08:34:54 +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 1sNEga-005sVR-LR for pgadmin-support@lists.postgresql.org; Fri, 28 Jun 2024 16:42:57 +0000 Received: from mail-ot1-x32e.google.com ([2607:f8b0:4864:20::32e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sNEgX-003ZpK-3T for pgadmin-support@postgresql.org; Fri, 28 Jun 2024 16:42:55 +0000 Received: by mail-ot1-x32e.google.com with SMTP id 46e09a7af769-6f8ffe1b65dso359050a34.0 for ; Fri, 28 Jun 2024 09:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1719592972; x=1720197772; 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=eIEDIWRmB7QK4YNeC65ESZpK2N/2l8iyfJXHbqbvNiA=; b=fUZvuwL6Q9eqec56tJwaHwHvEUwI0+cpVa38lVyMfKeXOQ1AkVdL8i02ChqCieilh+ o9ssamueSKDSbm164ja+igQf0G4VxKwptOsI3Rtvf1AmpuLv950swytOXYSQhfcQHIbN C8YEqg484vjjv59gZ+uYvdkVM/hmXTFz9YT1bVvv613/GZJ/xi0cQLPs0fXWaM/Jdsg0 4sQ13qrbqT4wVkV81ALTyA/YHhspLWtq2F+hjzd1q7NYWiTpD/8PV1zMaAa6a/kmIYIj OTraHtgayI96Pt9IHDmr4RepRbILDiDHB7q48kRHBDmpyFh1WZj9kYCzaErR/RKY4HYP eImA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719592972; x=1720197772; 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=eIEDIWRmB7QK4YNeC65ESZpK2N/2l8iyfJXHbqbvNiA=; b=bG2nzt0ydbHAHNWQSe9DKBYmgOMm2DAbudIQZKKvqv3mBc5LsYkre06FyaKEd9n09P RpkXzoVPAb+kdjZ6/OrG6RYDK6T79IWSmhbRtq30FOLPYlbAwv3KzEWZTX7YBqp4Rfv7 97KsX1BQh9mUm++I06537FsHhoB1DlDBBVBD25ZkGl6MHPoX7zkhsguhI7sSJLzZ2sHO VNPT9O8gFnmnyCBMWlvtR4XV7wCiPDPXJ/gUc37LtTj8gn2ZcT0hlpAVEjwhU+jwryGy 40AUgSo0kERj2UW9NTHgNj/CURhSzC70MjiXywfiVPMfX+iOS/X//ELsBbOE8dB7aItM m1wA== X-Gm-Message-State: AOJu0YwyEvPCCE78RxCAXntUD+pygyDWcYHPIdKgOc/2CsXilNFMc1nC CSA31bcLN6/EfbujCqbnsyFdbXD6Ks4y1nVMY+NbnFaAOw0+Cn8lK65mQn110LhuHjRAXQGLA7x RMRzvQqueP97IUxl//rWPbTIP6dDfmJ4tAmoW X-Google-Smtp-Source: AGHT+IFdp9WGFEc6wZFnAeDt+YM0m69FnWg4XtPNHr8w98FYAIcKnZx8gWIzvlDnvTAvQqYGhCTGXaXUKUCf9t2Y2Zw= X-Received: by 2002:a05:6830:3154:b0:700:cd0f:6cc5 with SMTP id 46e09a7af769-701faa9d60cmr1170201a34.7.1719592972205; Fri, 28 Jun 2024 09:42:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aditya Toshniwal Date: Fri, 28 Jun 2024 22:12:16 +0530 Message-ID: Subject: Re: Query tool data grid - Infinite scroll vs Pagination To: Edson Richter Cc: pgAdmin Support , pgadmin-hackers , Dave Page Content-Type: multipart/alternative; boundary="000000000000445385061bf5f00e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000445385061bf5f00e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Edson, The current implementation is infinite scroll. We're planning to replace/improve it. On Fri, Jun 28, 2024 at 6:48=E2=80=AFPM Edson Richter wrote: > Infinite scroll usually consume a lot of memory, and generate additional > overhead in case of copy data, export, etc. In my humble opinion, if > anything then paginated would work better without additional memory > consumption. > In case of implementing infinite scroll, please give users a option to > disable it. > > Thanks, > > Edson > > Obter o Outlook para Android > ------------------------------ > *From:* Aditya Toshniwal > *Sent:* Friday, June 28, 2024 5:33:45 AM > *To:* pgAdmin Support > *Cc:* pgadmin-hackers ; Dave Page < > dpage@pgadmin.org> > *Subject:* Re: Query tool data grid - Infinite scroll vs Pagination > > Hi, > > Unfortunately, there were only 3 responses to this. > In that case, we will discuss internally and decide what to do. > > On Thu, Jun 20, 2024 at 2:46=E2=80=AFPM Aditya Toshniwal < > aditya.toshniwal@enterprisedb.com> wrote: > > Hi Everyone, > > Request you to share your opinion on this and respond on: > > https://docs.google.com/forms/d/e/1FAIpQLSdfJhNK8qXSe9mKcubZa8jjjYl0hiZVx= hv6GGJo8WJcYc27ug/viewform?usp=3Dsharing > > On Thu, Jun 20, 2024 at 1:36=E2=80=AFPM Dave Page wro= te: > > Hi > > On Wed, 19 Jun 2024 at 13:42, Aditya Toshniwal < > aditya.toshniwal@enterprisedb.com> wrote: > > Hi Hackers, > > Query tool data grid currently pulls the data on load basis in batches. > For example, it will initially load only 1000 rows and once a user scroll= s > to the 1000th row, it will fetch the next batch of 1000. > Many users who want access in between rows or last row struggle to do it > as the user has to scroll and scroll. If someone grabs the scroller and > pulls it down still it will be a good UX and the scrollbar may jump. One > reported here - https://github.com/pgadmin-org/pgadmin4/issues/1780 > One more aspect to this is the in memory data of the query tool which kee= p > on increasing on each scroll, it affects the performance. > > I propose we should use pagination instead of infinite scroll with the > following advantages: > 1. Users can jump to any page they want. > 2. Users can change the page size on the grid directly. > 3. Memory will be used only for visible rows so performance improvement. > 4. Predictable UI, no jumping scrollbars. > > Let me know what you think. > > > > I think there are definite benefits, but there is the downside of having > to scroll and click to browse results. Personally I'm fine with that, but= I > think you should probably poll pgadmin-support for opinions from more use= rs. > > -- > Dave Page > pgAdmin: https://www.pgadmin.org > PostgreSQL: https://www.postgresql.org > EDB: https://www.enterprisedb.com > > > > -- > Thanks, > Aditya Toshniwal > pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com* > > "Don't Complain about Heat, Plant a TREE" > > > > -- > Thanks, > Aditya Toshniwal > pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com* > > "Don't Complain about Heat, Plant a TREE" > --=20 Thanks, Aditya Toshniwal pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com* "Don't Complain about Heat, Plant a TREE" --000000000000445385061bf5f00e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Edson,

The current implementation is infinite scroll. W= e're planning to replace/improve it.


On Fri, Jun 28, 2024 at = 6:48=E2=80=AFPM Edson Richter <edsonrichter@hotmail.com> wrote:
Infinite scroll usually consume a lot of memory, and gene= rate additional overhead in case of copy data, export, etc. In my humble op= inion, if anything then paginated would work better without additional memo= ry consumption.
In case of implementing infinite scroll, please give user= s a option to disable it.

Thanks,

Edson

From:= Aditya Toshniwal <aditya.toshniwal@enterprisedb.com>
Sent: Friday, June 28, 2024 5:33:45 AM
To: pgAdmin Support <pgadmin-support@postgresql.org>
Cc: pgadmin-hackers <pgadmin-hackers@postgresql.org>; Dave Page &= lt;dpage@pgadmin.org= >
Subject: Re: Query tool data grid - Infinite scroll vs Pagination
=C2=A0
Hi,

Unfortunately, there were onl= y 3 responses to this.
In that case, we will discuss= =C2=A0internally and decide what to do.

On Thu, Jun 20, 2024 at 2:46=E2=80=AFPM Aditya Toshniwal &= lt;a= ditya.toshniwal@enterprisedb.com> wrote:

On Thu, Jun 20, 2024 at 1:36=E2=80=AFPM Dave Page <dpage@pgadmin.org>= ; wrote:
Hi

On Wed, 19 Jun 2024 at 13:42, Aditya Toshniwal <aditya.tosh= niwal@enterprisedb.com> wrote:
Hi Hackers,

Query tool data grid currentl= y pulls the data on load basis in batches. For example, it will initially l= oad only 1000 rows and once a user scrolls to the 1000th row, it will fetch= the next batch of 1000.
Many users who want access in= between rows or last row struggle to do it as the user has to scroll and s= croll. If someone grabs the scroller and pulls it down still it will be a g= ood UX and the scrollbar may jump. One reported here -=C2=A0https://github.com/pgadmin-org/pgadmin4/is= sues/1780
One more aspect to this is th= e in memory data of the query tool which keep on increasing on each scroll,= it affects the performance.

I propose we should use pagin= ation instead of infinite scroll with the following advantages:
1. Users can jump to any page= they want.
2. Users can change the page = size on the grid directly.
3. Memory will be used only f= or visible rows so performance improvement.
4. Predictable UI, no jumping= scrollbars.

Let me know what=C2=A0you thi= nk.


I think there are definite benefits, but there is the downside of havi= ng to scroll and click to browse results. Personally I'm fine with that= , but I think you should probably poll pgadmin-support for opinions from mo= re users.

--


--
Thanks,<= /font>
Aditya Toshniwal
pgAdm= in Hacker=C2=A0| Sr. S<= /font>oftware= Architect=C2=A0| enterprisedb.com
&q= uot;Don't Complain about Heat, Plant a TREE"


--
Thanks,<= /font>
Aditya Toshniwal
pgAdm= in Hacker=C2=A0| Sr. S<= /font>oftware= Architect=C2=A0| enterprisedb.com
&q= uot;Don't Complain about Heat, Plant a TREE"


--
Thanks,
Aditya Toshniwal
pgAdmin Hacker=C2=A0| Sr. Software Architect=C2=A0| enterprisedb.com