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 1sKDwn-008w5I-Ol for pgadmin-hackers@arkaria.postgresql.org; Thu, 20 Jun 2024 09:19:13 +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 1sKDwl-0038t5-FF for pgadmin-hackers@arkaria.postgresql.org; Thu, 20 Jun 2024 09:19:12 +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 1sKDut-0035aX-GZ for pgadmin-hackers@lists.postgresql.org; Thu, 20 Jun 2024 09:17:16 +0000 Received: from mail-ot1-x32c.google.com ([2607:f8b0:4864:20::32c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sKDur-002cMz-Rk for pgadmin-hackers@postgresql.org; Thu, 20 Jun 2024 09:17:15 +0000 Received: by mail-ot1-x32c.google.com with SMTP id 46e09a7af769-6f8d0a00a35so595932a34.2 for ; Thu, 20 Jun 2024 02:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1718875031; x=1719479831; 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=pkQE8EfpBsZNRkDKZlyOoZT0NgTVh9FF+AMP1YnzWRo=; b=WzYLpNAPlv6kfNfTiPB/kNK4s+pw9V74GBXC8glDk2+w6yqFmeH4CIUt/0BZwBClR8 kQWdnT5BoneVBZtp0FcHOV8KwpqnweHQmGOH4nYsfJbaTDMvYsJiu+KOEEW7AYy8vo78 SG1nL2U+R6dWy8YjopsFdsrDjPP+/qDEhk8Kd0KmkN29hgRYf01SK6lnWErOo+gtqWft gQeHW5Wupd1lM/caHag4fS7WXAO1So+wRCv4Sl/VkUr3VLr2RKcQF8FxoObeMzgFjGIn r9nLfkp/QLo2kw/rqj/k0uYqWWLQ0lCoVBwk5X2LFOWcQjQDw4KmD46J1kdYxCFOWh5F AJeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718875031; x=1719479831; 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=pkQE8EfpBsZNRkDKZlyOoZT0NgTVh9FF+AMP1YnzWRo=; b=I/R9CMRAeih8Eq9V+FDhePVLslHPkTQRSXG9YOJz2m4O8l9sQgGGVLNP3zarYCEONw P+AHE+7/YTgFRcf6wimiMN1ezHywtWBHZDbnDT9onAb4CssmcJJkffORBBRb408s5Yp4 nXIUsV1n/EHj+bepGK1niIGaODn/zXn3sk1lTYP0ememaCsDglfhC8Uy2OfkuVH8SFdS HF5iqZSqbQqRy++uDcFnBRKY7xpvAsJ2hPEiCKU1RmyJwZfmnX2+coG6ygXAox/ukrC1 pjeDe6odZADYBLJa8VMYKa6KWYbU3OlifxSIcF1FpUJSXFVoW4BG2qqitdM9idRKIgbD g9lg== X-Gm-Message-State: AOJu0Yz2+X2SEENPiU6zXHq8vOueW/DypED12kM7D2nkPgKYFiPwLrBJ jCvM/7zfYSMWhzAWr/xvMzDSzqvNauMSxMttZyHPZ5L5UbC3QBY/KgYN+zOqsyKhfwNtuaz2cSb TBmll0JhcaBULHbFIup5TXHphy6/7kzLmAfUZ X-Google-Smtp-Source: AGHT+IFC4zaT03WAjUSPK37CEoBQEn2VNP9UPprgPFydZWD8lt017unHo8bUhn4cnRsyDL1jqmvxJoiaSMp7YNxDfyA= X-Received: by 2002:a05:6870:55cb:b0:255:1819:b442 with SMTP id 586e51a60fabf-25c949020efmr4896472fac.8.1718875031335; Thu, 20 Jun 2024 02:17:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aditya Toshniwal Date: Thu, 20 Jun 2024 14:46:34 +0530 Message-ID: Subject: Re: Query tool data grid - Infinite scroll vs Pagination To: pgAdmin Support Cc: pgadmin-hackers , Dave Page Content-Type: multipart/alternative; boundary="000000000000a81684061b4ec70d" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000a81684061b4ec70d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Everyone, Request you to share your opinion on this and respond on: https://docs.google.com/forms/d/e/1FAIpQLSdfJhNK8qXSe9mKcubZa8jjjYl0hiZVxhv= 6GGJo8WJcYc27ug/viewform?usp=3Dsharing On Thu, Jun 20, 2024 at 1:36=E2=80=AFPM Dave Page wrote= : > 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 scrol= ls >> 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 >> keep 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 > > --=20 Thanks, Aditya Toshniwal pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com* "Don't Complain about Heat, Plant a TREE" --000000000000a81684061b4ec70d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jun 20, 2024 at 1:36=E2=80=AFP= M Dave Page <dpage@pgadmin.org&= gt; wrote:
Hi

On Wed, 19 Jun 2024 at 13:42, Aditya Toshniwal <aditya.to= shniwal@enterprisedb.com> wrote:
Hi Hackers,
=
Query tool data gri= d currently pulls the data on load basis in batches. For example, it will i= nitially load 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 scroll. If someone grabs the scrolle= r and pulls it down still it will be a good UX and the scrollbar may jump. = One reported here -=C2=A0https://github.com/pgadmin-org/pgadmin4/iss= ues/1780
One mo= re aspect to this is the in memory data of the query tool which keep on inc= reasing 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=C2=A0you think.
=


I think there are def= inite 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 p= robably poll pgadmin-support for opinions from more users.


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