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 1sJudY-007JYZ-5K for pgadmin-hackers@arkaria.postgresql.org; Wed, 19 Jun 2024 12:42:04 +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 1sJudV-00Fpl6-KT for pgadmin-hackers@arkaria.postgresql.org; Wed, 19 Jun 2024 12:42:02 +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 1sJudV-00Fpky-CZ for pgadmin-hackers@lists.postgresql.org; Wed, 19 Jun 2024 12:42:02 +0000 Received: from mail-oo1-xc29.google.com ([2607:f8b0:4864:20::c29]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sJudS-002ShA-Fd for pgadmin-hackers@postgresql.org; Wed, 19 Jun 2024 12:42:00 +0000 Received: by mail-oo1-xc29.google.com with SMTP id 006d021491bc7-5bfa5f18ab0so1643678eaf.3 for ; Wed, 19 Jun 2024 05:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1718800916; x=1719405716; darn=postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=YMxcMm42LiFiOO4XPJ9QvRJtaUb5C7aUS4LOLCVMzpY=; b=TfYv8st14XOt/YjZIyUcKJ2u32nuntXZ4QJ7DKUecBo+by714BkHyCfLU/i8j+plMr HUaf4cU60wEKc3ElT6sw5fCVrUlb+ld0Lf39Y7XLM31VnRpIRK1XYp3YeizazArf7rhf CFzz8BwOClrU4xAVvjJxAqkRitGg/MScCUu+UIJ6RdFpO9r1RMzjpVEHFmlCseRnjatO SrHgiqBQh1nH44oQqqGxYTXmniiTX/gjbs5nFmpmO7l7io6BFE/nqOSyMRhUIGL2ppIz NtB/rAklekY9mAwgPCBWNXOLiI/zDBm55CpCCoU6V/zQQeGb/7fLhWk5DZA+mjG1DWPL Uidw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718800916; x=1719405716; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=YMxcMm42LiFiOO4XPJ9QvRJtaUb5C7aUS4LOLCVMzpY=; b=Xsmd0tBSoTnii2VAak+7OkDI7ak2viEdiABlzyHNUUvl14Q2A0wMqVQ9gBoC3VNwJa QWsY1eNKhTDni62kI8QerKEavNBPtQcYlVHTF2YSXz2FNL2hZOkexHNEMEHKbtZEOyH6 S/BpMDIK/QhApS0f6gDC4+IpVVPspC7eVVjXOrAFMX0+Py0PV3ggXdH/hXglNCzq3/Zq sQSn9bQeQhRRKMDCwh34a0gWg3mfEWywnkVfpyMtqKgiHssTaDrQl68LI7zLw9sRRrwf UX5+qrVl2j27oi0icHzGiJRwZn+z5E82IPpUbw28NNysBNvIAlAD0xhy95z/FCW64bMe rkog== X-Gm-Message-State: AOJu0YxeF7cjgQZhBrUuv8/qR+IA9kCCriGYp72zOZPYKdGOZ5h3g5KB dcDBNG6LekknvDkNwF/er4k8o5uMgJKUtO3RNcHWokrec6qk19a1Gv/2AEZFuGu7NeX2xNd+V6K 7VPlCvqjcY+vzphIVgHdmLLURMvgZ+75VH84W1v4piGdRS29q5w== X-Google-Smtp-Source: AGHT+IFilUBshH3YeljoAiINSzVd0oG77zNaO+Gt5D17btzEvRZ+Em0riFyMoqdYzqYn7bxFH41gTM5iyR8f0mmmvd0= X-Received: by 2002:a4a:9197:0:b0:5bd:ae80:865b with SMTP id 006d021491bc7-5c1adc653a1mr2724181eaf.9.1718800915791; Wed, 19 Jun 2024 05:41:55 -0700 (PDT) MIME-Version: 1.0 From: Aditya Toshniwal Date: Wed, 19 Jun 2024 18:11:19 +0530 Message-ID: Subject: Query tool data grid - Infinite scroll vs Pagination To: pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000069c62061b3d8651" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000069c62061b3d8651 Content-Type: text/plain; charset="UTF-8" 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 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. -- Thanks, Aditya Toshniwal pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com* "Don't Complain about Heat, Plant a TREE" --000000000000069c62061b3d8651 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hackers,

Query tool data grid currently pulls the data = on load basis in batches. For example, it will initially load only 1000 row= s and once a user scrolls to the 1000th row, it will fetch the next batch o= f 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 a= nd 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/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 sh= ould use pagination instead of infinite scroll with the following advantage= s:
1. Users can jump to any page they want.
2. Users can change the page si= ze on the grid directly.
3. Memory will be used only for visible rows so pe= rformance improvement.
4. Predictable UI, no jumping scrollbars.

=
Let m= e know what=C2=A0you think.


--
Thanks,
Aditya Toshniwal
pgAdmin Hacker= =C2=A0| Sr. S=C2=A0| enter= prisedb.com
"Don't Complain about Heat, P= lant a TREE"
--000000000000069c62061b3d8651--