Обсуждение: Re: Query tool data grid - Infinite scroll vs Pagination

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 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 users.

--

Dave Page

pgAdmin: https://www.pgadmin.org

PostgreSQL: https://www.postgresql.org

EDB: https://www.enterprisedb.com

Hi Everyone,

Request you to share your opinion on this and respond on:

https://docs.google.com/forms/d/e/1FAIpQLSdfJhNK8qXSe9mKcubZa8jjjYl0hiZVxhv6GGJo8WJcYc27ug/viewform?usp=sharing

On Thu, Jun 20, 2024 at 1:36 PM Dave Page <dpage@pgadmin.org> 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 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.

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 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"

Hi Everyone,

Request you to share your opinion on this and respond on:

https://docs.google.com/forms/d/e/1FAIpQLSdfJhNK8qXSe9mKcubZa8jjjYl0hiZVxhv6GGJo8WJcYc27ug/viewform?usp=sharing

On Thu, Jun 20, 2024 at 1:36 PM Dave Page <dpage@pgadmin.org> 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 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.

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 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"

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 <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 <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 PM 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/1FAIpQLSdfJhNK8qXSe9mKcubZa8jjjYl0hiZVxhv6GGJo8WJcYc27ug/viewform?usp=sharing

On Thu, Jun 20, 2024 at 1:36 PM Dave Page <dpage@pgadmin.org> 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 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.

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 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"

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 <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 <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 PM 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/1FAIpQLSdfJhNK8qXSe9mKcubZa8jjjYl0hiZVxhv6GGJo8WJcYc27ug/viewform?usp=sharing

On Thu, Jun 20, 2024 at 1:36 PM Dave Page <dpage@pgadmin.org> 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 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.

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 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"

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 PM 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/1FAIpQLSdfJhNK8qXSe9mKcubZa8jjjYl0hiZVxhv6GGJo8WJcYc27ug/viewform?usp=sharing

On Thu, Jun 20, 2024 at 1:36 PM Dave Page <dpage@pgadmin.org> 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 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.

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 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"

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 PM 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/1FAIpQLSdfJhNK8qXSe9mKcubZa8jjjYl0hiZVxhv6GGJo8WJcYc27ug/viewform?usp=sharing

On Thu, Jun 20, 2024 at 1:36 PM Dave Page <dpage@pgadmin.org> 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 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.

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 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"

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. 

On Fri, Jun 28, 2024 at 3:44 PM 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 PM 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/1FAIpQLSdfJhNK8qXSe9mKcubZa8jjjYl0hiZVxhv6GGJo8WJcYc27ug/viewform?usp=sharing

On Thu, Jun 20, 2024 at 1:36 PM Dave Page <dpage@pgadmin.org> 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 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.

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 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"

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. 

On Fri, Jun 28, 2024 at 3:44 PM 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 PM 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/1FAIpQLSdfJhNK8qXSe9mKcubZa8jjjYl0hiZVxhv6GGJo8WJcYc27ug/viewform?usp=sharing

On Thu, Jun 20, 2024 at 1:36 PM Dave Page <dpage@pgadmin.org> 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 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.

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 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"

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 AM 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. 

On Fri, Jun 28, 2024 at 3:44 PM 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 PM 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/1FAIpQLSdfJhNK8qXSe9mKcubZa8jjjYl0hiZVxhv6GGJo8WJcYc27ug/viewform?usp=sharing

On Thu, Jun 20, 2024 at 1:36 PM Dave Page <dpage@pgadmin.org> 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 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.

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 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"

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 AM 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. 

On Fri, Jun 28, 2024 at 3:44 PM 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 PM 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/1FAIpQLSdfJhNK8qXSe9mKcubZa8jjjYl0hiZVxhv6GGJo8WJcYc27ug/viewform?usp=sharing

On Thu, Jun 20, 2024 at 1:36 PM Dave Page <dpage@pgadmin.org> 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 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.

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 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"

I think there's a nice blend between pagination and infinite scrolling.

The problem with the current infinite scrolling implementation is that the scroll baris scaled to the number of *rendered* rows, so as you scroll down (which renders another bunch of records), it keeps rescaling the scrollbar, so to get the next "page", you have to continually move to the scrollbar (as Aditya says, "Many users who want access in between rows or last row struggle to do it as the user has to scroll and scroll.")

If instead the scrollbar were scaled to the total number of rows, (e.g., 1000 rather than the initial 25 rows that were rendered), then clicking (say) in the lower third of the scrollbar would would do enough fetching/rendering to display rows 601-625 (or such).  Problem solved.

Alternatively (or additionally), provide a "jump to row..." button (similar to what Usman is suggesting re pagination) that gives the user control to see a specific bunch of records quickly.

But if the issue is that people don't like infinite scrolling because "the user has to scroll and scroll", then fix that specific UE issue, and people will be happy.

The concern I have with a paginated solution is if the page represents the maximum number of rows rendered in the results pane, at any one time.  Assume I can see 25 rows in the result pane.  I.e., you show rows 1-25 for the first page, then you only show rows 26-50 for the second page, then only show rows 27-50, etc. But when there is a cluster of records of interest between rows 640 and 655, then those records of interest are going to be spread between pages 25 and 26, and will constantly require flipping back and forth between pages.  This would be possibly worse UE than the current "user has to scroll and scroll" issue.  On the other hand, if your pagination solution includes letting someone nudge the rendered rows up or down a bit so that I can see rows 640-655 all at once (e.g., there's a field where I can type in that the current page should start at row 635, so I can see rows 640-655 all together), then I'm fine with that.

However, if ultimately you decide to toss out infinite scrolling for pagination, then please make the (default?) page size be the number of rows you can actually see in the result pane, rather than some arbitrary number (e.g., 50).  Having the page size equal to the number of rendered rows means I can quickly step through the pages and hopefully notice a record of interest.... If the page size is larger than the number of rendered rows, then as I step to the next page I still have to scroll down to see the last few rows, then step to the next page, then scroll down again,  I.e., that would be hideous UE!

So my vote preferences are:

First choice: keep infinite scrolling, but simply fix the scrollbar scaling and/or give the user the means to quickly jump down by a page or to a specific page

Second choice: use pagination, but only if there's the ability to see a specific chunk of records on a single page (rather than spread across two), and make the pagination size default to the number of records visible given the height of the result pane

Cheers,

Dave

On Mon, 1 Jul 2024 at 04:35, 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. 

On Fri, Jun 28, 2024 at 3:44 PM 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 PM 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/1FAIpQLSdfJhNK8qXSe9mKcubZa8jjjYl0hiZVxhv6GGJo8WJcYc27ug/viewform?usp=sharing

On Thu, Jun 20, 2024 at 1:36 PM Dave Page <dpage@pgadmin.org> 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 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.

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 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"

I think there's a nice blend between pagination and infinite scrolling.

The problem with the current infinite scrolling implementation is that the scroll baris scaled to the number of *rendered* rows, so as you scroll down (which renders another bunch of records), it keeps rescaling the scrollbar, so to get the next "page", you have to continually move to the scrollbar (as Aditya says, "Many users who want access in between rows or last row struggle to do it as the user has to scroll and scroll.")

If instead the scrollbar were scaled to the total number of rows, (e.g., 1000 rather than the initial 25 rows that were rendered), then clicking (say) in the lower third of the scrollbar would would do enough fetching/rendering to display rows 601-625 (or such).  Problem solved.

Alternatively (or additionally), provide a "jump to row..." button (similar to what Usman is suggesting re pagination) that gives the user control to see a specific bunch of records quickly.

But if the issue is that people don't like infinite scrolling because "the user has to scroll and scroll", then fix that specific UE issue, and people will be happy.

The concern I have with a paginated solution is if the page represents the maximum number of rows rendered in the results pane, at any one time.  Assume I can see 25 rows in the result pane.  I.e., you show rows 1-25 for the first page, then you only show rows 26-50 for the second page, then only show rows 27-50, etc. But when there is a cluster of records of interest between rows 640 and 655, then those records of interest are going to be spread between pages 25 and 26, and will constantly require flipping back and forth between pages.  This would be possibly worse UE than the current "user has to scroll and scroll" issue.  On the other hand, if your pagination solution includes letting someone nudge the rendered rows up or down a bit so that I can see rows 640-655 all at once (e.g., there's a field where I can type in that the current page should start at row 635, so I can see rows 640-655 all together), then I'm fine with that.

However, if ultimately you decide to toss out infinite scrolling for pagination, then please make the (default?) page size be the number of rows you can actually see in the result pane, rather than some arbitrary number (e.g., 50).  Having the page size equal to the number of rendered rows means I can quickly step through the pages and hopefully notice a record of interest.... If the page size is larger than the number of rendered rows, then as I step to the next page I still have to scroll down to see the last few rows, then step to the next page, then scroll down again,  I.e., that would be hideous UE!

So my vote preferences are:

First choice: keep infinite scrolling, but simply fix the scrollbar scaling and/or give the user the means to quickly jump down by a page or to a specific page

Second choice: use pagination, but only if there's the ability to see a specific chunk of records on a single page (rather than spread across two), and make the pagination size default to the number of records visible given the height of the result pane

Cheers,

Dave

On Mon, 1 Jul 2024 at 04:35, 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. 

On Fri, Jun 28, 2024 at 3:44 PM 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 PM 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/1FAIpQLSdfJhNK8qXSe9mKcubZa8jjjYl0hiZVxhv6GGJo8WJcYc27ug/viewform?usp=sharing

On Thu, Jun 20, 2024 at 1:36 PM Dave Page <dpage@pgadmin.org> 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 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.

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 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"