On Thu, Jun 16, 2016 at 1:43 PM, Akshay Joshi <akshay.jo...@enterprisedb.com > wrote:
> > > On Thu, Jun 16, 2016 at 6:09 PM, Dave Page <dp...@pgadmin.org> wrote: > >> >> >> On Thu, Jun 16, 2016 at 1:34 PM, Akshay Joshi < >> akshay.jo...@enterprisedb.com> wrote: >> >>> >>> >>> On Thu, Jun 16, 2016 at 5:47 PM, Khushboo Vashi < >>> khushboo.va...@enterprisedb.com> wrote: >>> >>>> >>>> >>>> On Thu, Jun 16, 2016 at 5:07 PM, Dave Page <dp...@pgadmin.org> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Jun 16, 2016 at 12:19 PM, Khushboo Vashi < >>>>> khushboo.va...@enterprisedb.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Thu, Jun 16, 2016 at 4:42 PM, Dave Page <dp...@pgadmin.org> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jun 16, 2016 at 12:04 PM, Akshay Joshi < >>>>>>> akshay.jo...@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 <dp...@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
