Re: pgAdmin 4 commit: Cleanup handling of default/null values when data edi

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Surinder Kumar <surinder(dot)kumar(at)enterprisedb(dot)com>
Cc: Harshal Dhumal <harshal(dot)dhumal(at)enterprisedb(dot)com>, pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: pgAdmin 4 commit: Cleanup handling of default/null values when data edi
Date: 2017-05-30 15:22:28
Message-ID: CA+OCxoyj0znGTXCcFYd6-qt8QkUamg4pNcwN10Zu=Ad3pguRsg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

Thanks, applied.

On Mon, May 29, 2017 at 7:08 AM, Surinder Kumar
<surinder(dot)kumar(at)enterprisedb(dot)com> wrote:
> Hi Dave,
>
> The grid was being re-rendered after add new row and copy/paste to add a
> blank row in the end of grid, but in case of copy/paste batch operation it
> should run once, so that code is moved out of addNewRow(...) and put into a
> function grid.addBlankRow() and called separately for copy/paste after batch
> operation is completed.
>
> Now copy/paste with 10k records took 2 seconds.
>
> Please find attached patch.
>
>
> On Mon, May 29, 2017 at 5:19 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>
>> On Sun, May 28, 2017 at 1:25 PM, Harshal Dhumal
>> <harshal(dot)dhumal(at)enterprisedb(dot)com> wrote:
>> > Hi,
>> >
>> > This commit has some performance issues with row paste functionality.
>> > For 2K copied rows with 3 columns (2 integer and one null column) it
>> > took
>> > near about 10 seconds to complete paste operation. And entire
>> > application
>> > becomes unresponsive for those 10 seconds.
>> >
>> > This is mainly because for each single pasted row entire grid is
>> > re-rendered
>> > ( is what I see in code).
>> > Ideally grid should be re-rendered only once after all rows are provided
>> > to
>> > grid.
>> >
>> > below code snippet from _paste_rows function
>> >
>> > _.each(copied_rows, function(row) {
>> > var new_row = arr_to_object(row);
>> > new_row.is_row_copied = true;
>> > row = new_row;
>> > self.temp_new_rows.push(count);
>> > grid.onAddNewRow.notify(
>> > {item: new_row, column: self.columns[0] , grid:grid}
>> > )
>> > grid.setSelectedRows([]);
>> > count++;
>> > });
>> >
>> > The statement
>> >
>> > grid.onAddNewRow.notify(
>> > {item: new_row, column: self.columns[0] , grid:grid}
>> > )
>> >
>> > causes grid to re-render (as we listener on onAddNewRow event where we
>> > re-render the grid)
>>
>> Copying that number of rows is an extreme case of course, but still...
>> Is there an alternative way to batch notify?
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>
>

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

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

In response to

Browse pgadmin-hackers by date

  From Date Subject
Next Message Dave Page 2017-05-30 15:31:59 Re: [pgAdmin4][RM_2424]: Menu Items don't appear in tools menu for modules that are loaded using deps
Previous Message Dave Page 2017-05-30 15:22:15 pgAdmin 4 commit: Avoid re-rendering the edit grid for every row that i