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 1sOYVN-0001cQ-Sq for pgadmin-support@arkaria.postgresql.org; Tue, 02 Jul 2024 08:04:50 +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 1sOYUN-000AY2-RW for pgadmin-support@arkaria.postgresql.org; Tue, 02 Jul 2024 08:03:48 +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 1sOGMy-001XtR-Mb; Mon, 01 Jul 2024 12:42:57 +0000 Received: from mail-pf1-x433.google.com ([2607:f8b0:4864:20::433]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sOGMv-004UEv-0n; Mon, 01 Jul 2024 12:42:55 +0000 Received: by mail-pf1-x433.google.com with SMTP id d2e1a72fcca58-701b0b0be38so2314392b3a.0; Mon, 01 Jul 2024 05:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719837771; x=1720442571; 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=zk2i1aqydIUC3ZFHuRyQRdCAu5Cu9MSiWTyEquZ2FFg=; b=lrdPrkaw4I2dNzHjdKPFj8zdza1Jel3fKK6wEBOSwMmZKdTYUdzSKHR3TuDDt2EVlo ZnfBTM19GfrgyItdJpGzq5HcYc+PKCaVuGA6dLstPNFNHIS81k96X4B/2J3F1xgDzRM7 ECzvlPxLANMcs3QFkIOVifM7ejkJKhH/MnCZBupXFpkn8oiMahWcZmmdmL/FqdIczgkq NaBKuXCj49E/inbXW9W/hKJmk+tZmoN2JMcs26B6sInn7afS6aL3dQ37l+snz1UU3MOL chd6syK9K9p1Ee58Eo0geIHo0SA7UJ7550pfpWW5mwxDxOgYWeUgUDaD1AqRH7EHiJt1 dQSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719837771; x=1720442571; 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=zk2i1aqydIUC3ZFHuRyQRdCAu5Cu9MSiWTyEquZ2FFg=; b=nnhMO1ihUjXQK3OrzgFRNuN3kmatMmhGs6cmfupWCUkfcCLQ/4JEf8z8hhDfXOD2Y3 FitYFs+PZmYOaknc4gLGTbWxDhXHBAyPbhAXccrl4VeA52m52zwjQ53R6XRHJAD4ykUd 9ZNXQ2CHWINBRVabb+HezwJz8qoCY6zKHo6z36TtNyX85ieX2lpyBA2y5TVQr39c0YS7 kKSmZ80fORS+lpV/jc4xhryyxnww/0js2LN/Zeto8IdCpUF5L2PxQqbRqyszIwq4eYV+ 3+2jFH4qNRIO2gmNdP3vrab5ihj3dfvUY7UALn1eGroS9dblBuizy3ccKHRKFMO+DquF efKA== X-Forwarded-Encrypted: i=1; AJvYcCUOPC14TN76UGFAomIn2TVO2zP70zL8bfAvs8wxFHPBCfj5NnL6YOyuZiO2+h7JoSqt1qcmQb03BAKtitt77CmzWj2w9+ZWLgEJSKska210x/w2kfNl+0YI2ti+BUZV/49genrFgWKI+v34qEWvbQ== X-Gm-Message-State: AOJu0YxZOV6AoMPAIcSosoNw4DVDG/rTQcO/HIrWcTUTgzrl3aFYaxxE UGHS7OjmQ5/TXHbcBXeCKEc3jmyfsqTMm4Vwni8C7J08IL2RjcaWTuHTs2/l97AQcYoKQ8uXTgw DY0vtreagtEbSuXzsaFFOV70UO/I= X-Google-Smtp-Source: AGHT+IE0i5eEk1ejZPl9CHQc8Tc6n3IhOO9s3mGBt6Sa56eF42Mp8oxmiob08XUrQKAs9JaXMrg7kFaeCM2455PE9t0= X-Received: by 2002:a05:6a00:c96:b0:706:1edc:79af with SMTP id d2e1a72fcca58-70aaaf08d9amr6507943b3a.22.1719837770931; Mon, 01 Jul 2024 05:42:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Anthony DeBarros Date: Mon, 1 Jul 2024 08:42:14 -0400 Message-ID: Subject: Re: Query tool data grid - Infinite scroll vs Pagination To: Usman Khan Cc: Aditya Toshniwal , pgAdmin Support , pgadmin-hackers , Dave Page Content-Type: multipart/alternative; boundary="0000000000006863dc061c2eef6f" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000006863dc061c2eef6f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If I may add, please have pgAdmin display the total number of rows in the result set regardless of pagination page size. On Mon, Jul 1, 2024 at 4:35=E2=80=AFAM Usman Khan wrote: > Hi Aditya > I vote for pagination, it would really be helpful for end users. > In addition to giving the user the ability to set page size, if he can > also select or enter what page he can jump to say 501, 990 etc it would b= e > helpful. > > On Fri, Jun 28, 2024 at 3:44=E2=80=AFPM Aditya Toshniwal < > aditya.toshniwal@enterprisedb.com> wrote: > >> 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/1FAIpQLSdfJhNK8qXSe9mKcubZa8jjjYl0hiZ= Vxhv6GGJo8WJcYc27ug/viewform?usp=3Dsharing >>> >>> On Thu, Jun 20, 2024 at 1:36=E2=80=AFPM Dave Page w= rote: >>> >>>> 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 >>>>> 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 - 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 th= e >>>>> 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 opinion= s >>>> from more users. >>>> >>>> -- >>>> 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" >> > --0000000000006863dc061c2eef6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If I may add, please have pgAdmin display the total number= of rows in the result set regardless of pagination page size.

On Mon, Jul 1= , 2024 at 4:35=E2=80=AFAM Usman Khan <umk555@gmail.com> wrote:
Hi Aditya
I vote for pagination, it = would really be helpful for end users.
In addition to giving the = user the ability to set page size, if he can also select or enter what page= he can jump to say 501, 990 etc it would be helpful.=C2=A0
=
On Fri= , Jun 28, 2024 at 3:44=E2=80=AFPM Aditya Toshniwal <aditya.toshniwal@enterpr= isedb.com> wrote:
Hi,

Unfortunately, there were only 3 responses = to this.
In that case, we will discuss=C2=A0internally and decide what to d= o.

On Thu, Jun 20, 2024 at 2:46=E2=80=AFPM Aditya Toshniwal <aditya.tos= hniwal@enterprisedb.com> wrote:
Hi Everyone,

Request you to share = your opinion on this and respond on:
https://docs.google.com/forms/d/e/1FAIpQLSdf= JhNK8qXSe9mKcubZa8jjjYl0hiZVxhv6GGJo8WJcYc27ug/viewform?usp=3Dsharing

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

On Wed, 19 Jun 2024 at 13:42, Aditya Toshniwal <aditya.toshniwal@enterpr= isedb.com> wrote:
H= i Hackers,

Query tool data grid currently p= ulls the data on load basis in batches. For example, it will initially load= only 1000 rows and once a user scrolls to the 1000th row, it will fetch th= e next batch of 1000.
Ma= ny users who want access in between rows or last row struggle to do it as t= he user has to scroll and scroll. If someone grabs the scroller and pulls i= t down still it will be a good UX and the scrollbar may jump. One reported = here -=C2=A0https://github.com/pgadmin-org/pgadmin4/issues/1780<= /div>
One more aspect to = this is the in memory data of the query tool which keep on increasing on ea= ch scroll, it affects the performance.

I pr= opose we should use pagination instead of infinite scroll with the followin= g advantages:
1. Users c= an jump to any page they want.
2. Users can change the page size on the grid directly.
3. Memory will be used only for visi= ble rows so performance improvement.
4. Predictable UI, no jumping scrollbars.

Let me know what=C2=A0you think.
=


I think there are definite benefit= s, but there is the downside of having to scroll and click to browse result= s. Personally I'm fine with that, but I think you should probably poll = pgadmin-support for opinions from more users.

--


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

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