Re: Fixed RM #1356

From: Akshay Joshi <akshay(dot)joshi(at)enterprisedb(dot)com>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: Khushboo Vashi <khushboo(dot)vashi(at)enterprisedb(dot)com>, Ashesh Vashi <ashesh(dot)vashi(at)enterprisedb(dot)com>, pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: Fixed RM #1356
Date: 2016-06-16 12:43:55
Message-ID: CANxoLDcsy6cu5m-Q7tcapbHjT9ZX2jzg1w480oS663Ln2bwcoQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

On Thu, Jun 16, 2016 at 6:09 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:

>
>
> On Thu, Jun 16, 2016 at 1:34 PM, Akshay Joshi <
> akshay(dot)joshi(at)enterprisedb(dot)com> wrote:
>
>>
>>
>> On Thu, Jun 16, 2016 at 5:47 PM, Khushboo Vashi <
>> khushboo(dot)vashi(at)enterprisedb(dot)com> wrote:
>>
>>>
>>>
>>> On Thu, Jun 16, 2016 at 5:07 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Jun 16, 2016 at 12:19 PM, Khushboo Vashi <
>>>> khushboo(dot)vashi(at)enterprisedb(dot)com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Jun 16, 2016 at 4:42 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jun 16, 2016 at 12:04 PM, Akshay Joshi <
>>>>>> akshay(dot)joshi(at)enterprisedb(dot)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(at)pgadmin(dot)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?

>
> --
> 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-9517Mobile: +91 976-788-8246*

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message Dave Page 2016-06-16 13:18:43 Re: Fixed RM #1356
Previous Message Dave Page 2016-06-16 12:39:37 Re: Fixed RM #1356