Re: Fixed RM #1356

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

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

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