Thread: Fixed RM #1356

Hi 

I have fixed RM #1356 "Query tool enhancement". I have added the logic to preferences which checks the min/max value before setting it. If value given by user is less than min value then set it to min value and if value is greater then max value then set it to max value.

For "items_per_page" minimum value is 1. Attached is the patch file. Please review it.   

Hi

On Wed, Jun 15, 2016 at 11:27 AM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi 

I have fixed RM #1356 "Query tool enhancement". I have added the logic to preferences which checks the min/max value before setting it. If value given by user is less than min value then set it to min value and if value is greater then max value then set it to max value.

For "items_per_page" minimum value is 1. Attached is the patch file. Please review it.   

That doesn't do what I asked for though. A value of zero should be acceptable (I did say <= 0, but = 0 is probably better), and mean 'disable paging' (i.e. display unlimited rows, and completely hide the paging controls). From the ticket:

1) If "Items per page in grid" <= 0, then never page results. Add a note to that effect on the Preferences pane, and make zero the default value.

The patch does appear to implement:

2) Always allow the user to add a new row in Edit Grid mode. If and only if there are multiple pages, warn the user ("The result set display will move to the last page. Do you wish to continue?"), then move to the last page and add the new row. If there is only one page, just add the new row.

However, if the new row requires a new page to be added (i.e. rows per page is 10, and you press the + button to add the 11th, 21st...51st row), the user needs to manually advance a page. I guess the auto advance needs to happen after the row is added?

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Wed, Jun 15, 2016 at 5:25 PM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Wed, Jun 15, 2016 at 11:27 AM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi 

I have fixed RM #1356 "Query tool enhancement". I have added the logic to preferences which checks the min/max value before setting it. If value given by user is less than min value then set it to min value and if value is greater then max value then set it to max value.

For "items_per_page" minimum value is 1. Attached is the patch file. Please review it.   

That doesn't do what I asked for though. A value of zero should be acceptable (I did say <= 0, but = 0 is probably better), and mean 'disable paging' (i.e. display unlimited rows, and completely hide the paging controls). From the ticket:

1) If "Items per page in grid" <= 0, then never page results. Add a note to that effect on the Preferences pane, and make zero the default value.

The patch does appear to implement:

    Backbone's Pageble Collection don't allow Zero value. Below is the check present in "backbone.paginator.js" file:

      

        if (pageSize < 1) {

          throw new RangeError("`pageSize` must be >= 1");

        }

    because of that I have set the minimum default value to 1.

2) Always allow the user to add a new row in Edit Grid mode. If and only if there are multiple pages, warn the user ("The result set display will move to the last page. Do you wish to continue?"), then move to the last page and add the new row. If there is only one page, just add the new row.

However, if the new row requires a new page to be added (i.e. rows per page is 10, and you press the + button to add the 11th, 21st...51st row), the user needs to manually advance a page. I guess the auto advance needs to happen after the row is added?

   Will do that. 

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--

Akshay Joshi

Principal Software Engineer 

Phone: +91 20-3058-9517
Mobile: +91 976-788-8246

On Wed, Jun 15, 2016 at 5:44 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Wed, Jun 15, 2016 at 5:25 PM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Wed, Jun 15, 2016 at 11:27 AM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi 

I have fixed RM #1356 "Query tool enhancement". I have added the logic to preferences which checks the min/max value before setting it. If value given by user is less than min value then set it to min value and if value is greater then max value then set it to max value.

For "items_per_page" minimum value is 1. Attached is the patch file. Please review it.   

That doesn't do what I asked for though. A value of zero should be acceptable (I did say <= 0, but = 0 is probably better), and mean 'disable paging' (i.e. display unlimited rows, and completely hide the paging controls). From the ticket:

1) If "Items per page in grid" <= 0, then never page results. Add a note to that effect on the Preferences pane, and make zero the default value.

The patch does appear to implement:

    Backbone's Pageble Collection don't allow Zero value. Below is the check present in "backbone.paginator.js" file:

      

        if (pageSize < 1) {

          throw new RangeError("`pageSize` must be >= 1");

        }

We can avoid using the Pageable Collection in our code, when pageSize is <= 0 to fix the issue. 

On Wed, Jun 15, 2016 at 1:16 PM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:

On Wed, Jun 15, 2016 at 5:44 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Wed, Jun 15, 2016 at 5:25 PM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Wed, Jun 15, 2016 at 11:27 AM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi 

I have fixed RM #1356 "Query tool enhancement". I have added the logic to preferences which checks the min/max value before setting it. If value given by user is less than min value then set it to min value and if value is greater then max value then set it to max value.

For "items_per_page" minimum value is 1. Attached is the patch file. Please review it.   

That doesn't do what I asked for though. A value of zero should be acceptable (I did say <= 0, but = 0 is probably better), and mean 'disable paging' (i.e. display unlimited rows, and completely hide the paging controls). From the ticket:

1) If "Items per page in grid" <= 0, then never page results. Add a note to that effect on the Preferences pane, and make zero the default value.

The patch does appear to implement:

    Backbone's Pageble Collection don't allow Zero value. Below is the check present in "backbone.paginator.js" file:

      

        if (pageSize < 1) {

          throw new RangeError("`pageSize` must be >= 1");

        }

We can avoid using the Pageable Collection in our code, when pageSize is <= 0 to fix the issue. 

Exactly. The entire point of the change is to default to not paging at all.

BTW, this may be helpful (also missed from the original patch): 

help_str=gettext('The number of rows to display per page in the results grid. A value of 0 will disable paging.'),

 

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Thanks, patch applied.

However, whilst I was testing, I saw just how slow the tool is:

SELECT * FROM pg_attribute

In a PEM database, returns 8150 rows. In pgAdmin 3, this is timed at 676ms on my laptop. In pgAdmin 4, the busy spinner runs for approx 5 seconds, then the whole UI freezes. I then have to wait a further 3 minutes and 46 seconds(!!!!) for the operation to complete. Once loaded, scrolling is very sluggish.

Please make this your top priority - and if you have incremental improvements, send them as you have them.

On Wed, Jun 15, 2016 at 4:50 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi 

Please ignore the last patch. Attached is the latest patch. Please review it.

On Wed, Jun 15, 2016 at 9:10 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi

On Wed, Jun 15, 2016 at 5:54 PM, Dave Page <dpage@pgadmin.org> wrote:

On Wed, Jun 15, 2016 at 1:16 PM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:

On Wed, Jun 15, 2016 at 5:44 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Wed, Jun 15, 2016 at 5:25 PM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Wed, Jun 15, 2016 at 11:27 AM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi 

I have fixed RM #1356 "Query tool enhancement". I have added the logic to preferences which checks the min/max value before setting it. If value given by user is less than min value then set it to min value and if value is greater then max value then set it to max value.

For "items_per_page" minimum value is 1. Attached is the patch file. Please review it.   

That doesn't do what I asked for though. A value of zero should be acceptable (I did say <= 0, but = 0 is probably better), and mean 'disable paging' (i.e. display unlimited rows, and completely hide the paging controls). From the ticket:

1) If "Items per page in grid" <= 0, then never page results. Add a note to that effect on the Preferences pane, and make zero the default value.

The patch does appear to implement:

    Backbone's Pageble Collection don't allow Zero value. Below is the check present in "backbone.paginator.js" file:

      

        if (pageSize < 1) {

          throw new RangeError("`pageSize` must be >= 1");

        }

We can avoid using the Pageable Collection in our code, when pageSize is <= 0 to fix the issue. 

Exactly. The entire point of the change is to default to not paging at all.

BTW, this may be helpful (also missed from the original patch): 

help_str=gettext('The number of rows to display per page in the results grid. A value of 0 will disable paging.'),

   Fixed above as per suggestion. Attached is the modified patch file. Please review it.   

 

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--

Akshay Joshi

Principal Software Engineer 

Phone: +91 20-3058-9517
Mobile: +91 976-788-8246

--

Akshay Joshi

Principal Software Engineer 

Phone: +91 20-3058-9517
Mobile: +91 976-788-8246

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Thu, Jun 16, 2016 at 2:35 PM, Dave Page <dpage@pgadmin.org> wrote:

Thanks, patch applied.

However, whilst I was testing, I saw just how slow the tool is:

SELECT * FROM pg_attribute

In a PEM database, returns 8150 rows. In pgAdmin 3, this is timed at 676ms on my laptop. In pgAdmin 4, the busy spinner runs for approx 5 seconds, then the whole UI freezes. I then have to wait a further 3 minutes and 46 seconds(!!!!) for the operation to complete. Once loaded, scrolling is very sluggish.

Please make this your top priority - and if you have incremental improvements, send them as you have them.

   Sure. 

On Wed, Jun 15, 2016 at 4:50 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi 

Please ignore the last patch. Attached is the latest patch. Please review it.

On Wed, Jun 15, 2016 at 9:10 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi

On Wed, Jun 15, 2016 at 5:54 PM, Dave Page <dpage@pgadmin.org> wrote:

On Wed, Jun 15, 2016 at 1:16 PM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:

On Wed, Jun 15, 2016 at 5:44 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Wed, Jun 15, 2016 at 5:25 PM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Wed, Jun 15, 2016 at 11:27 AM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi 

I have fixed RM #1356 "Query tool enhancement". I have added the logic to preferences which checks the min/max value before setting it. If value given by user is less than min value then set it to min value and if value is greater then max value then set it to max value.

For "items_per_page" minimum value is 1. Attached is the patch file. Please review it.   

That doesn't do what I asked for though. A value of zero should be acceptable (I did say <= 0, but = 0 is probably better), and mean 'disable paging' (i.e. display unlimited rows, and completely hide the paging controls). From the ticket:

1) If "Items per page in grid" <= 0, then never page results. Add a note to that effect on the Preferences pane, and make zero the default value.

The patch does appear to implement:

    Backbone's Pageble Collection don't allow Zero value. Below is the check present in "backbone.paginator.js" file:

      

        if (pageSize < 1) {

          throw new RangeError("`pageSize` must be >= 1");

        }

We can avoid using the Pageable Collection in our code, when pageSize is <= 0 to fix the issue. 

Exactly. The entire point of the change is to default to not paging at all.

BTW, this may be helpful (also missed from the original patch): 

help_str=gettext('The number of rows to display per page in the results grid. A value of 0 will disable paging.'),

   Fixed above as per suggestion. Attached is the modified patch file. Please review it.   

 

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--

Akshay Joshi

Principal Software Engineer 

Phone: +91 20-3058-9517
Mobile: +91 976-788-8246

--

Akshay Joshi

Principal Software Engineer 

Phone: +91 20-3058-9517
Mobile: +91 976-788-8246

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--

Akshay Joshi

Principal Software Engineer 

Phone: +91 20-3058-9517
Mobile: +91 976-788-8246

Hi Dave

On Thu, Jun 16, 2016 at 2:42 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 2:35 PM, Dave Page <dpage@pgadmin.org> wrote:

Thanks, patch applied.

However, whilst I was testing, I saw just how slow the tool is:

SELECT * FROM pg_attribute

In a PEM database, returns 8150 rows. In pgAdmin 3, this is timed at 676ms on my laptop. In pgAdmin 4, the busy spinner runs for approx 5 seconds, then the whole UI freezes. I then have to wait a further 3 minutes and 46 seconds(!!!!) for the operation to complete. Once loaded, scrolling is very sluggish.

Please make this your top priority - and if you have incremental improvements, send them as you have them.

   Sure. 

      Below is my initial finding while running "SELECT * FROM pg_attribute" on PEM database, returns 8498 rows:

• Fetching data from the server side took consistent time and it took 3-4 secs.
• Create/Render Backgrid without pagination : 1 minute
• Create/Render Backgrid with pagination (50 items per page):  469ms
  
• Create/Render Backgrid with pagination (500 items per page): 3 secs
  
• Create/Render Backgrid with pagination (1000 items per page): 6 secs
  
• Create/Render Backgrid with pagination (3000 items per page): 22 secs
  
• Create/Render Backgrid with pagination (5000 items per page): 36 secs

• 
  

On Wed, Jun 15, 2016 at 4:50 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi 

Please ignore the last patch. Attached is the latest patch. Please review it.

On Wed, Jun 15, 2016 at 9:10 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi

On Wed, Jun 15, 2016 at 5:54 PM, Dave Page <dpage@pgadmin.org> wrote:

On Wed, Jun 15, 2016 at 1:16 PM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:

On Wed, Jun 15, 2016 at 5:44 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Wed, Jun 15, 2016 at 5:25 PM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Wed, Jun 15, 2016 at 11:27 AM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi 

I have fixed RM #1356 "Query tool enhancement". I have added the logic to preferences which checks the min/max value before setting it. If value given by user is less than min value then set it to min value and if value is greater then max value then set it to max value.

For "items_per_page" minimum value is 1. Attached is the patch file. Please review it.   

That doesn't do what I asked for though. A value of zero should be acceptable (I did say <= 0, but = 0 is probably better), and mean 'disable paging' (i.e. display unlimited rows, and completely hide the paging controls). From the ticket:

1) If "Items per page in grid" <= 0, then never page results. Add a note to that effect on the Preferences pane, and make zero the default value.

The patch does appear to implement:

    Backbone's Pageble Collection don't allow Zero value. Below is the check present in "backbone.paginator.js" file:

      

        if (pageSize < 1) {

          throw new RangeError("`pageSize` must be >= 1");

        }

We can avoid using the Pageable Collection in our code, when pageSize is <= 0 to fix the issue. 

Exactly. The entire point of the change is to default to not paging at all.

BTW, this may be helpful (also missed from the original patch): 

help_str=gettext('The number of rows to display per page in the results grid. A value of 0 will disable paging.'),

   Fixed above as per suggestion. Attached is the modified patch file. Please review it.   

 

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--

Akshay Joshi

Principal Software Engineer 

Phone: +91 20-3058-9517
Mobile: +91 976-788-8246

--

Akshay Joshi

Principal Software Engineer 

Phone: +91 20-3058-9517
Mobile: +91 976-788-8246

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--

Akshay Joshi

Principal Software Engineer 

Phone: +91 20-3058-9517
Mobile: +91 976-788-8246

--

Akshay Joshi

Principal Software Engineer 

Phone: +91 20-3058-9517
Mobile: +91 976-788-8246

On Thu, Jun 16, 2016 at 12:04 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi Dave

On Thu, Jun 16, 2016 at 2:42 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 2:35 PM, Dave Page <dpage@pgadmin.org> wrote:

Thanks, patch applied.

However, whilst I was testing, I saw just how slow the tool is:

SELECT * FROM pg_attribute

In a PEM database, returns 8150 rows. In pgAdmin 3, this is timed at 676ms on my laptop. In pgAdmin 4, the busy spinner runs for approx 5 seconds, then the whole UI freezes. I then have to wait a further 3 minutes and 46 seconds(!!!!) for the operation to complete. Once loaded, scrolling is very sluggish.

Please make this your top priority - and if you have incremental improvements, send them as you have them.

   Sure. 

      Below is my initial finding while running "SELECT * FROM pg_attribute" on PEM database, returns 8498 rows:

• Fetching data from the server side took consistent time and it took 3-4 secs.
• Create/Render Backgrid without pagination : 1 minute
• Create/Render Backgrid with pagination (50 items per page):  469ms
  
• Create/Render Backgrid with pagination (500 items per page): 3 secs
  
• Create/Render Backgrid with pagination (1000 items per page): 6 secs
  
• Create/Render Backgrid with pagination (3000 items per page): 22 secs
  
• Create/Render Backgrid with pagination (5000 items per page): 36 secs

OK, so I guess diving into Backgrid is the next step. Are there any profiling tools that could be used?

 

• 
  

On Wed, Jun 15, 2016 at 4:50 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi 

Please ignore the last patch. Attached is the latest patch. Please review it.

On Wed, Jun 15, 2016 at 9:10 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi

On Wed, Jun 15, 2016 at 5:54 PM, Dave Page <dpage@pgadmin.org> wrote:

On Wed, Jun 15, 2016 at 1:16 PM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:

On Wed, Jun 15, 2016 at 5:44 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Wed, Jun 15, 2016 at 5:25 PM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Wed, Jun 15, 2016 at 11:27 AM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi 

I have fixed RM #1356 "Query tool enhancement". I have added the logic to preferences which checks the min/max value before setting it. If value given by user is less than min value then set it to min value and if value is greater then max value then set it to max value.

For "items_per_page" minimum value is 1. Attached is the patch file. Please review it.   

That doesn't do what I asked for though. A value of zero should be acceptable (I did say <= 0, but = 0 is probably better), and mean 'disable paging' (i.e. display unlimited rows, and completely hide the paging controls). From the ticket:

1) If "Items per page in grid" <= 0, then never page results. Add a note to that effect on the Preferences pane, and make zero the default value.

The patch does appear to implement:

    Backbone's Pageble Collection don't allow Zero value. Below is the check present in "backbone.paginator.js" file:

      

        if (pageSize < 1) {

          throw new RangeError("`pageSize` must be >= 1");

        }

We can avoid using the Pageable Collection in our code, when pageSize is <= 0 to fix the issue. 

Exactly. The entire point of the change is to default to not paging at all.

BTW, this may be helpful (also missed from the original patch): 

help_str=gettext('The number of rows to display per page in the results grid. A value of 0 will disable paging.'),

   Fixed above as per suggestion. Attached is the modified patch file. Please review it.   

 

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--

Akshay Joshi

Principal Software Engineer 

Phone: +91 20-3058-9517
Mobile: +91 976-788-8246

--

Akshay Joshi

Principal Software Engineer 

Phone: +91 20-3058-9517
Mobile: +91 976-788-8246

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--

Akshay Joshi

Principal Software Engineer 

Phone: +91 20-3058-9517
Mobile: +91 976-788-8246

--

Akshay Joshi

Principal Software Engineer 

Phone: +91 20-3058-9517
Mobile: +91 976-788-8246

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Thu, Jun 16, 2016 at 4:42 PM, Dave Page <dpage@pgadmin.org> wrote:

On Thu, Jun 16, 2016 at 12:04 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi Dave

On Thu, Jun 16, 2016 at 2:42 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 2:35 PM, Dave Page <dpage@pgadmin.org> wrote:

Thanks, patch applied.

However, whilst I was testing, I saw just how slow the tool is:

SELECT * FROM pg_attribute

In a PEM database, returns 8150 rows. In pgAdmin 3, this is timed at 676ms on my laptop. In pgAdmin 4, the busy spinner runs for approx 5 seconds, then the whole UI freezes. I then have to wait a further 3 minutes and 46 seconds(!!!!) for the operation to complete. Once loaded, scrolling is very sluggish.

Please make this your top priority - and if you have incremental improvements, send them as you have them.

   Sure. 

      Below is my initial finding while running "SELECT * FROM pg_attribute" on PEM database, returns 8498 rows:

• Fetching data from the server side took consistent time and it took 3-4 secs.
• Create/Render Backgrid without pagination : 1 minute
• Create/Render Backgrid with pagination (50 items per page):  469ms
  
• Create/Render Backgrid with pagination (500 items per page): 3 secs
  
• Create/Render Backgrid with pagination (1000 items per page): 6 secs
  
• Create/Render Backgrid with pagination (3000 items per page): 22 secs
  
• Create/Render Backgrid with pagination (5000 items per page): 36 secs

OK, so I guess diving into Backgrid is the next step. Are there any profiling tools that could be used?

 

 

Can we use infinity scrolling in case of no pagination?  

On Thu, Jun 16, 2016 at 12:19 PM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 4:42 PM, Dave Page <dpage@pgadmin.org> wrote:

On Thu, Jun 16, 2016 at 12:04 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi Dave

On Thu, Jun 16, 2016 at 2:42 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 2:35 PM, Dave Page <dpage@pgadmin.org> wrote:

Thanks, patch applied.

However, whilst I was testing, I saw just how slow the tool is:

SELECT * FROM pg_attribute

In a PEM database, returns 8150 rows. In pgAdmin 3, this is timed at 676ms on my laptop. In pgAdmin 4, the busy spinner runs for approx 5 seconds, then the whole UI freezes. I then have to wait a further 3 minutes and 46 seconds(!!!!) for the operation to complete. Once loaded, scrolling is very sluggish.

Please make this your top priority - and if you have incremental improvements, send them as you have them.

   Sure. 

      Below is my initial finding while running "SELECT * FROM pg_attribute" on PEM database, returns 8498 rows:

• Fetching data from the server side took consistent time and it took 3-4 secs.
• Create/Render Backgrid without pagination : 1 minute
• Create/Render Backgrid with pagination (50 items per page):  469ms
  
• Create/Render Backgrid with pagination (500 items per page): 3 secs
  
• Create/Render Backgrid with pagination (1000 items per page): 6 secs
  
• Create/Render Backgrid with pagination (3000 items per page): 22 secs
  
• Create/Render Backgrid with pagination (5000 items per page): 36 secs

OK, so I guess diving into Backgrid is the next step. Are there any profiling tools that could be used?

 

 

Can we use infinity scrolling in case of no pagination?  

How would add row work then? 

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Thu, Jun 16, 2016 at 5:07 PM, Dave Page <dpage@pgadmin.org> wrote:

On Thu, Jun 16, 2016 at 12:19 PM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 4:42 PM, Dave Page <dpage@pgadmin.org> wrote:

On Thu, Jun 16, 2016 at 12:04 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi Dave

On Thu, Jun 16, 2016 at 2:42 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 2:35 PM, Dave Page <dpage@pgadmin.org> wrote:

Thanks, patch applied.

However, whilst I was testing, I saw just how slow the tool is:

SELECT * FROM pg_attribute

In a PEM database, returns 8150 rows. In pgAdmin 3, this is timed at 676ms on my laptop. In pgAdmin 4, the busy spinner runs for approx 5 seconds, then the whole UI freezes. I then have to wait a further 3 minutes and 46 seconds(!!!!) for the operation to complete. Once loaded, scrolling is very sluggish.

Please make this your top priority - and if you have incremental improvements, send them as you have them.

   Sure. 

      Below is my initial finding while running "SELECT * FROM pg_attribute" on PEM database, returns 8498 rows:

• Fetching data from the server side took consistent time and it took 3-4 secs.
• Create/Render Backgrid without pagination : 1 minute
• Create/Render Backgrid with pagination (50 items per page):  469ms
  
• Create/Render Backgrid with pagination (500 items per page): 3 secs
  
• Create/Render Backgrid with pagination (1000 items per page): 6 secs
  
• Create/Render Backgrid with pagination (3000 items per page): 22 secs
  
• Create/Render Backgrid with pagination (5000 items per page): 36 secs

OK, so I guess diving into Backgrid is the next step. Are there any profiling tools that could be used?

 

 

Can we use infinity scrolling in case of no pagination?  

How would add row work then? 

Yeah, in this case user has to wait till the last record to load. :(

Btw, I was thinking of https://github.com/bhvaleri/backgrid-infinator

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Thu, Jun 16, 2016 at 5:47 PM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 5:07 PM, Dave Page <dpage@pgadmin.org> wrote:

On Thu, Jun 16, 2016 at 12:19 PM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 4:42 PM, Dave Page <dpage@pgadmin.org> wrote:

On Thu, Jun 16, 2016 at 12:04 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi Dave

On Thu, Jun 16, 2016 at 2:42 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 2:35 PM, Dave Page <dpage@pgadmin.org> wrote:

Thanks, patch applied.

However, whilst I was testing, I saw just how slow the tool is:

SELECT * FROM pg_attribute

In a PEM database, returns 8150 rows. In pgAdmin 3, this is timed at 676ms on my laptop. In pgAdmin 4, the busy spinner runs for approx 5 seconds, then the whole UI freezes. I then have to wait a further 3 minutes and 46 seconds(!!!!) for the operation to complete. Once loaded, scrolling is very sluggish.

Please make this your top priority - and if you have incremental improvements, send them as you have them.

   Sure. 

      Below is my initial finding while running "SELECT * FROM pg_attribute" on PEM database, returns 8498 rows:

• Fetching data from the server side took consistent time and it took 3-4 secs.
• Create/Render Backgrid without pagination : 1 minute
• Create/Render Backgrid with pagination (50 items per page):  469ms
  
• Create/Render Backgrid with pagination (500 items per page): 3 secs
  
• Create/Render Backgrid with pagination (1000 items per page): 6 secs
  
• Create/Render Backgrid with pagination (3000 items per page): 22 secs
  
• Create/Render Backgrid with pagination (5000 items per page): 36 secs

OK, so I guess diving into Backgrid is the next step. Are there any profiling tools that could be used?

 

 

Can we use infinity scrolling in case of no pagination?  

How would add row work then? 

Yeah, in this case user has to wait till the last record to load. :(

Btw, I was thinking of https://github.com/bhvaleri/backgrid-infinator

    This seems to be the good option. 

On Thu, Jun 16, 2016 at 1:34 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 5:47 PM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 5:07 PM, Dave Page <dpage@pgadmin.org> wrote:

On Thu, Jun 16, 2016 at 12:19 PM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 4:42 PM, Dave Page <dpage@pgadmin.org> wrote:

On Thu, Jun 16, 2016 at 12:04 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi Dave

On Thu, Jun 16, 2016 at 2:42 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 2:35 PM, Dave Page <dpage@pgadmin.org> wrote:

Thanks, patch applied.

However, whilst I was testing, I saw just how slow the tool is:

SELECT * FROM pg_attribute

In a PEM database, returns 8150 rows. In pgAdmin 3, this is timed at 676ms on my laptop. In pgAdmin 4, the busy spinner runs for approx 5 seconds, then the whole UI freezes. I then have to wait a further 3 minutes and 46 seconds(!!!!) for the operation to complete. Once loaded, scrolling is very sluggish.

Please make this your top priority - and if you have incremental improvements, send them as you have them.

   Sure. 

      Below is my initial finding while running "SELECT * FROM pg_attribute" on PEM database, returns 8498 rows:

• Fetching data from the server side took consistent time and it took 3-4 secs.
• Create/Render Backgrid without pagination : 1 minute
• Create/Render Backgrid with pagination (50 items per page):  469ms
  
• Create/Render Backgrid with pagination (500 items per page): 3 secs
  
• Create/Render Backgrid with pagination (1000 items per page): 6 secs
  
• Create/Render Backgrid with pagination (3000 items per page): 22 secs
  
• Create/Render Backgrid with pagination (5000 items per page): 36 secs

OK, so I guess diving into Backgrid is the next step. Are there any profiling tools that could be used?

 

 

Can we use infinity scrolling in case of no pagination?  

How would add row work then? 

Yeah, in this case user has to wait till the last record to load. :(

Btw, I was thinking of https://github.com/bhvaleri/backgrid-infinator

    This seems to be the good option. 

No - please see my previous comment. 

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Thu, Jun 16, 2016 at 6:09 PM, Dave Page <dpage@pgadmin.org> wrote:

On Thu, Jun 16, 2016 at 1:34 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 5:47 PM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 5:07 PM, Dave Page <dpage@pgadmin.org> wrote:

On Thu, Jun 16, 2016 at 12:19 PM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 4:42 PM, Dave Page <dpage@pgadmin.org> wrote:

On Thu, Jun 16, 2016 at 12:04 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi Dave

On Thu, Jun 16, 2016 at 2:42 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 2:35 PM, Dave Page <dpage@pgadmin.org> wrote:

Thanks, patch applied.

However, whilst I was testing, I saw just how slow the tool is:

SELECT * FROM pg_attribute

In a PEM database, returns 8150 rows. In pgAdmin 3, this is timed at 676ms on my laptop. In pgAdmin 4, the busy spinner runs for approx 5 seconds, then the whole UI freezes. I then have to wait a further 3 minutes and 46 seconds(!!!!) for the operation to complete. Once loaded, scrolling is very sluggish.

Please make this your top priority - and if you have incremental improvements, send them as you have them.

   Sure. 

      Below is my initial finding while running "SELECT * FROM pg_attribute" on PEM database, returns 8498 rows:

• Fetching data from the server side took consistent time and it took 3-4 secs.
• Create/Render Backgrid without pagination : 1 minute
• Create/Render Backgrid with pagination (50 items per page):  469ms
  
• Create/Render Backgrid with pagination (500 items per page): 3 secs
  
• Create/Render Backgrid with pagination (1000 items per page): 6 secs
  
• Create/Render Backgrid with pagination (3000 items per page): 22 secs
  
• Create/Render Backgrid with pagination (5000 items per page): 36 secs

OK, so I guess diving into Backgrid is the next step. Are there any profiling tools that could be used?

 

 

Can we use infinity scrolling in case of no pagination?  

How would add row work then? 

Yeah, in this case user has to wait till the last record to load. :(

Btw, I was thinking of https://github.com/bhvaleri/backgrid-infinator

    This seems to be the good option. 

No - please see my previous comment. 

    We can add/paste row as top row of the backgrid. In that case will it be fine?

On Thu, Jun 16, 2016 at 1:43 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 6:09 PM, Dave Page <dpage@pgadmin.org> wrote:

On Thu, Jun 16, 2016 at 1:34 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 5:47 PM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 5:07 PM, Dave Page <dpage@pgadmin.org> wrote:

On Thu, Jun 16, 2016 at 12:19 PM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 4:42 PM, Dave Page <dpage@pgadmin.org> wrote:

On Thu, Jun 16, 2016 at 12:04 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi Dave

On Thu, Jun 16, 2016 at 2:42 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 2:35 PM, Dave Page <dpage@pgadmin.org> wrote:

Thanks, patch applied.

However, whilst I was testing, I saw just how slow the tool is:

SELECT * FROM pg_attribute

In a PEM database, returns 8150 rows. In pgAdmin 3, this is timed at 676ms on my laptop. In pgAdmin 4, the busy spinner runs for approx 5 seconds, then the whole UI freezes. I then have to wait a further 3 minutes and 46 seconds(!!!!) for the operation to complete. Once loaded, scrolling is very sluggish.

Please make this your top priority - and if you have incremental improvements, send them as you have them.

   Sure. 

      Below is my initial finding while running "SELECT * FROM pg_attribute" on PEM database, returns 8498 rows:

• Fetching data from the server side took consistent time and it took 3-4 secs.
• Create/Render Backgrid without pagination : 1 minute
• Create/Render Backgrid with pagination (50 items per page):  469ms
  
• Create/Render Backgrid with pagination (500 items per page): 3 secs
  
• Create/Render Backgrid with pagination (1000 items per page): 6 secs
  
• Create/Render Backgrid with pagination (3000 items per page): 22 secs
  
• Create/Render Backgrid with pagination (5000 items per page): 36 secs

OK, so I guess diving into Backgrid is the next step. Are there any profiling tools that could be used?

 

 

Can we use infinity scrolling in case of no pagination?  

How would add row work then? 

Yeah, in this case user has to wait till the last record to load. :(

Btw, I was thinking of https://github.com/bhvaleri/backgrid-infinator

    This seems to be the good option. 

No - please see my previous comment. 

    We can add/paste row as top row of the backgrid. In that case will it be fine?

It's a hack, it doesn't solve the underlying problem. The fact that it took 4 minutes to load 8000 rows on my top-of-the-range MacBook Pro is not good. 

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Hi Dave

On Thu, Jun 16, 2016 at 6:48 PM, Dave Page <dpage@pgadmin.org> wrote:

On Thu, Jun 16, 2016 at 1:43 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 6:09 PM, Dave Page <dpage@pgadmin.org> wrote:

On Thu, Jun 16, 2016 at 1:34 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 5:47 PM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 5:07 PM, Dave Page <dpage@pgadmin.org> wrote:

On Thu, Jun 16, 2016 at 12:19 PM, Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 4:42 PM, Dave Page <dpage@pgadmin.org> wrote:

On Thu, Jun 16, 2016 at 12:04 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

Hi Dave

On Thu, Jun 16, 2016 at 2:42 PM, Akshay Joshi <akshay.joshi@enterprisedb.com> wrote:

On Thu, Jun 16, 2016 at 2:35 PM, Dave Page <dpage@pgadmin.org> wrote:

Thanks, patch applied.

However, whilst I was testing, I saw just how slow the tool is:

SELECT * FROM pg_attribute

In a PEM database, returns 8150 rows. In pgAdmin 3, this is timed at 676ms on my laptop. In pgAdmin 4, the busy spinner runs for approx 5 seconds, then the whole UI freezes. I then have to wait a further 3 minutes and 46 seconds(!!!!) for the operation to complete. Once loaded, scrolling is very sluggish.

Please make this your top priority - and if you have incremental improvements, send them as you have them.

   Sure. 

      Below is my initial finding while running "SELECT * FROM pg_attribute" on PEM database, returns 8498 rows:

• Fetching data from the server side took consistent time and it took 3-4 secs.
• Create/Render Backgrid without pagination : 1 minute
• Create/Render Backgrid with pagination (50 items per page):  469ms
  
• Create/Render Backgrid with pagination (500 items per page): 3 secs
  
• Create/Render Backgrid with pagination (1000 items per page): 6 secs
  
• Create/Render Backgrid with pagination (3000 items per page): 22 secs
  
• Create/Render Backgrid with pagination (5000 items per page): 36 secs

OK, so I guess diving into Backgrid is the next step. Are there any profiling tools that could be used?

 

 

Can we use infinity scrolling in case of no pagination?  

How would add row work then? 

Yeah, in this case user has to wait till the last record to load. :(

Btw, I was thinking of https://github.com/bhvaleri/backgrid-infinator

    This seems to be the good option. 

No - please see my previous comment. 

    We can add/paste row as top row of the backgrid. In that case will it be fine?

It's a hack, it doesn't solve the underlying problem. The fact that it took 4 minutes to load 8000 rows on my top-of-the-range MacBook Pro is not good. 

   I have tried to fix the issue, but unable to figure out any way to do it .  I have tried following options 

• Same issue found here https://github.com/wyuenho/backgrid/issues/126  Which will be fixed https://github.com/wyuenho/backgrid/pull/444. I have copied the backgrid.js and backgrid.css from "perf" branch replace it in our code, but faced so many error's and warning, fixed those but some how data is not rendered.

• Another approach is instead of adding all the records to the backbone collection at once, I have added them in chunk of 500 records at a time and sleep for 500ms, in this case busy spinner won't run for a longer time as first 500 records gets rendered, but browser again goes into unresponsive state as CPU goes up to 98-99%.

On Fri, Jun 17, 2016 at 4:25 PM, Ashesh Vashi
<ashesh.vashi@enterprisedb.com> wrote:
>
> On Jun 17, 2016 20:53, "Dave Page" <dpage@pgadmin.org> wrote:
>>
>>
>>
>> On Fri, Jun 17, 2016 at 4:04 PM, Akshay Joshi
>> <akshay.joshi@enterprisedb.com> wrote:
>>>
>>> Hi Dave
>>>
>>> On Thu, Jun 16, 2016 at 6:48 PM, Dave Page <dpage@pgadmin.org> wrote:
>>>>
>>>>
>>>>
>>>> On Thu, Jun 16, 2016 at 1:43 PM, Akshay Joshi
>>>> <akshay.joshi@enterprisedb.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jun 16, 2016 at 6:09 PM, Dave Page <dpage@pgadmin.org> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jun 16, 2016 at 1:34 PM, Akshay Joshi
>>>>>> <akshay.joshi@enterprisedb.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jun 16, 2016 at 5:47 PM, Khushboo Vashi
>>>>>>> <khushboo.vashi@enterprisedb.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Jun 16, 2016 at 5:07 PM, Dave Page <dpage@pgadmin.org>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Jun 16, 2016 at 12:19 PM, Khushboo Vashi
>>>>>>>>> <khushboo.vashi@enterprisedb.com> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Jun 16, 2016 at 4:42 PM, Dave Page <dpage@pgadmin.org>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jun 16, 2016 at 12:04 PM, Akshay Joshi
>>>>>>>>>>> <akshay.joshi@enterprisedb.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Dave
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jun 16, 2016 at 2:42 PM, Akshay Joshi
>>>>>>>>>>>> <akshay.joshi@enterprisedb.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Jun 16, 2016 at 2:35 PM, Dave Page <dpage@pgadmin.org>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks, patch applied.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> However, whilst I was testing, I saw just how slow the tool
>>>>>>>>>>>>>> is:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> SELECT * FROM pg_attribute
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In a PEM database, returns 8150 rows. In pgAdmin 3, this is
>>>>>>>>>>>>>> timed at 676ms on my laptop. In pgAdmin 4, the busy spinner runs for approx
>>>>>>>>>>>>>> 5 seconds, then the whole UI freezes. I then have to wait a further 3
>>>>>>>>>>>>>> minutes and 46 seconds(!!!!) for the operation to complete. Once loaded,
>>>>>>>>>>>>>> scrolling is very sluggish.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please make this your top priority - and if you have
>>>>>>>>>>>>>> incremental improvements, send them as you have them.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>    Sure.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>       Below is my initial finding while running "SELECT * FROM
>>>>>>>>>>>> pg_attribute" on PEM database, returns 8498 rows:
>>>>>>>>>>>> Fetching data from the server side took consistent time and it
>>>>>>>>>>>> took 3-4 secs.
>>>>>>>>>>>> Create/Render Backgrid without pagination : 1 minute
>>>>>>>>>>>> Create/Render Backgrid with pagination (50 items per page):
>>>>>>>>>>>> 469ms
>>>>>>>>>>>> Create/Render Backgrid with pagination (500 items per page): 3
>>>>>>>>>>>> secs
>>>>>>>>>>>> Create/Render Backgrid with pagination (1000 items per page): 6
>>>>>>>>>>>> secs
>>>>>>>>>>>> Create/Render Backgrid with pagination (3000 items per page): 22
>>>>>>>>>>>> secs
>>>>>>>>>>>> Create/Render Backgrid with pagination (5000 items per page): 36
>>>>>>>>>>>> secs
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> OK, so I guess diving into Backgrid is the next step. Are there
>>>>>>>>>>> any profiling tools that could be used?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Can we use infinity scrolling in case of no pagination?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> How would add row work then?
>>>>>>>>
>>>>>>>>
>>>>>>>> Yeah, in this case user has to wait till the last record to load. :(
>>>>>>>> Btw, I was thinking of
>>>>>>>> https://github.com/bhvaleri/backgrid-infinator
>>>>>>>
>>>>>>>
>>>>>>>     This seems to be the good option.
>>>>>>
>>>>>>
>>>>>> No - please see my previous comment.
>>>>>
>>>>>
>>>>>     We can add/paste row as top row of the backgrid. In that case will
>>>>> it be fine?
>>>>
>>>>
>>>> It's a hack, it doesn't solve the underlying problem. The fact that it
>>>> took 4 minutes to load 8000 rows on my top-of-the-range MacBook Pro is not
>>>> good.
>>>
>>>
>>>    I have tried to fix the issue, but unable to figure out any way to do
>>> it .  I have tried following options
>>> Same issue found here https://github.com/wyuenho/backgrid/issues/126
>>> Which will be fixed https://github.com/wyuenho/backgrid/pull/444. I have
>>> copied the backgrid.js and backgrid.css from "perf" branch replace it in our
>>> code, but faced so many error's and warning, fixed those but some how data
>>> is not rendered.
>>
>> Hmm, that's so old I'm not holding my breath about it being included in a
>> hurry.
>>
>>>
>>> Another approach is instead of adding all the records to the backbone
>>> collection at once, I have added them in chunk of 500 records at a time and
>>> sleep for 500ms, in this case busy spinner won't run for a longer time as
>>> first 500 records gets rendered, but browser again goes into unresponsive
>>> state as CPU goes up to 98-99%.
>>
>> Urgh. I wonder if we need a different grid control for this, something
>> like SlickGrid which is extremely fast with large data sets.
>>
>> https://github.com/6pac/SlickGrid
> That's what I was researching about.
> But - we need to research on adding row, copy rows, etc.

The examples (http://mleibman.github.io/SlickGrid/examples/) certainly
look promising - it can add/edit rows, copy/paste arbitrary selections
etc. It can even display graphs in cells, or use templates for
rendering them.

There are also a couple of shims to backbone out there, though I'm not
sure if that would just slow things down again.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Hi Dave

On Fri, Jun 17, 2016 at 9:00 PM, Dave Page <dpage@pgadmin.org> wrote:

On Fri, Jun 17, 2016 at 4:25 PM, Ashesh Vashi
<ashesh.vashi@enterprisedb.com> wrote:
>
> On Jun 17, 2016 20:53, "Dave Page" <dpage@pgadmin.org> wrote:
>>
>>
>>
>> On Fri, Jun 17, 2016 at 4:04 PM, Akshay Joshi
>> <akshay.joshi@enterprisedb.com> wrote:
>>>
>>> Hi Dave
>>>
>>> On Thu, Jun 16, 2016 at 6:48 PM, Dave Page <dpage@pgadmin.org> wrote:
>>>>
>>>>
>>>>
>>>> On Thu, Jun 16, 2016 at 1:43 PM, Akshay Joshi
>>>> <akshay.joshi@enterprisedb.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jun 16, 2016 at 6:09 PM, Dave Page <dpage@pgadmin.org> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jun 16, 2016 at 1:34 PM, Akshay Joshi
>>>>>> <akshay.joshi@enterprisedb.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jun 16, 2016 at 5:47 PM, Khushboo Vashi
>>>>>>> <khushboo.vashi@enterprisedb.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Jun 16, 2016 at 5:07 PM, Dave Page <dpage@pgadmin.org>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Jun 16, 2016 at 12:19 PM, Khushboo Vashi
>>>>>>>>> <khushboo.vashi@enterprisedb.com> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Jun 16, 2016 at 4:42 PM, Dave Page <dpage@pgadmin.org>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jun 16, 2016 at 12:04 PM, Akshay Joshi
>>>>>>>>>>> <akshay.joshi@enterprisedb.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Dave
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jun 16, 2016 at 2:42 PM, Akshay Joshi
>>>>>>>>>>>> <akshay.joshi@enterprisedb.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Jun 16, 2016 at 2:35 PM, Dave Page <dpage@pgadmin.org>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks, patch applied.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> However, whilst I was testing, I saw just how slow the tool
>>>>>>>>>>>>>> is:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> SELECT * FROM pg_attribute
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In a PEM database, returns 8150 rows. In pgAdmin 3, this is
>>>>>>>>>>>>>> timed at 676ms on my laptop. In pgAdmin 4, the busy spinner runs for approx
>>>>>>>>>>>>>> 5 seconds, then the whole UI freezes. I then have to wait a further 3
>>>>>>>>>>>>>> minutes and 46 seconds(!!!!) for the operation to complete. Once loaded,
>>>>>>>>>>>>>> scrolling is very sluggish.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please make this your top priority - and if you have
>>>>>>>>>>>>>> incremental improvements, send them as you have them.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>    Sure.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>       Below is my initial finding while running "SELECT * FROM
>>>>>>>>>>>> pg_attribute" on PEM database, returns 8498 rows:
>>>>>>>>>>>> Fetching data from the server side took consistent time and it
>>>>>>>>>>>> took 3-4 secs.
>>>>>>>>>>>> Create/Render Backgrid without pagination : 1 minute
>>>>>>>>>>>> Create/Render Backgrid with pagination (50 items per page):
>>>>>>>>>>>> 469ms
>>>>>>>>>>>> Create/Render Backgrid with pagination (500 items per page): 3
>>>>>>>>>>>> secs
>>>>>>>>>>>> Create/Render Backgrid with pagination (1000 items per page): 6
>>>>>>>>>>>> secs
>>>>>>>>>>>> Create/Render Backgrid with pagination (3000 items per page): 22
>>>>>>>>>>>> secs
>>>>>>>>>>>> Create/Render Backgrid with pagination (5000 items per page): 36
>>>>>>>>>>>> secs
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> OK, so I guess diving into Backgrid is the next step. Are there
>>>>>>>>>>> any profiling tools that could be used?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Can we use infinity scrolling in case of no pagination?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> How would add row work then?
>>>>>>>>
>>>>>>>>
>>>>>>>> Yeah, in this case user has to wait till the last record to load. :(
>>>>>>>> Btw, I was thinking of
>>>>>>>> https://github.com/bhvaleri/backgrid-infinator
>>>>>>>
>>>>>>>
>>>>>>>     This seems to be the good option.
>>>>>>
>>>>>>
>>>>>> No - please see my previous comment.
>>>>>
>>>>>
>>>>>     We can add/paste row as top row of the backgrid. In that case will
>>>>> it be fine?
>>>>
>>>>
>>>> It's a hack, it doesn't solve the underlying problem. The fact that it
>>>> took 4 minutes to load 8000 rows on my top-of-the-range MacBook Pro is not
>>>> good.
>>>
>>>
>>>    I have tried to fix the issue, but unable to figure out any way to do
>>> it .  I have tried following options
>>> Same issue found here https://github.com/wyuenho/backgrid/issues/126
>>> Which will be fixed https://github.com/wyuenho/backgrid/pull/444. I have
>>> copied the backgrid.js and backgrid.css from "perf" branch replace it in our
>>> code, but faced so many error's and warning, fixed those but some how data
>>> is not rendered.
>>
>> Hmm, that's so old I'm not holding my breath about it being included in a
>> hurry.
>>
>>>
>>> Another approach is instead of adding all the records to the backbone
>>> collection at once, I have added them in chunk of 500 records at a time and
>>> sleep for 500ms, in this case busy spinner won't run for a longer time as
>>> first 500 records gets rendered, but browser again goes into unresponsive
>>> state as CPU goes up to 98-99%.
>>
>> Urgh. I wonder if we need a different grid control for this, something
>> like SlickGrid which is extremely fast with large data sets.
>>
>> https://github.com/6pac/SlickGrid
> That's what I was researching about.
> But - we need to research on adding row, copy rows, etc.

The examples (http://mleibman.github.io/SlickGrid/examples/) certainly
look promising - it can add/edit rows, copy/paste arbitrary selections
etc. It can even display graphs in cells, or use templates for
rendering them.

There are also a couple of shims to backbone out there, though I'm not
sure if that would just slow things down again.

   Should we start working on SlickGrid. If we are planning to use this, first we will have to identify the feature's given in the Query Tool would be possible with SlickGrid and also It will take time to implement.

If not then we shouldn't allow user to set items per page = 0 (no pagination), we should set the minimum(50 or 100) and maximum(2000-2500) value for the time being to avoid the issue.