Re: Query Tool Slow to Load

Yeah, I'll give it a go. If you don't hear back from me in a week, it
probably means I'm lost in the void between two AMD modules. Is there a
WebStorm or VSCode extension that will help me cross that gap? ctrl + click
to go to definition doesn't seem to work.

On Mon, Aug 5, 2019 at 5:31 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:

> Hi
>
> Yes - we were talking about that last week as it happens:
> https://redmine.postgresql.org/issues/4553
>
> Is this something you're interested to work on?
>
> On Mon, Aug 5, 2019 at 12:56 PM Avin Kavish <avinkavish(at)gmail(dot)com> wrote:
>
>> To Dave and maintainers,
>>
>> Here's when the click event handler triggers,
>> [image: Query open.jpg]
>> Here is the first loading screen,
>> [image: query loading.jpg]
>> It takes 3.8 - 1.5 = 2.3s for the loading screen to show up.
>>
>>
>> Here's when the query tool is ready to use,
>> [image: Query close.jpg]
>>
>> It takes 4.7s - 1.5s = 3.2s total for the query tool to be ready since
>> click, 0.9s for UI instantiation.
>>
>> So, I looked at what is causing the delay, there is an ajax request to
>> initialize_datagrid that takes 2s to complete. It's primary job is to
>> return a transaction id under the key `gridTransId` after making the
>> connection to the database. Obviously, dns, ssl, and password
>> authentication to a remote database is going to incur delays. There is
>> nothing that can be done to prevent that. BUT, there is no need to delay
>> the loading of the query editor till the transaction id is received.
>>
>> this.on('pgadmin-datagrid:transaction:created', function(trans_obj) {
>> this.launch_grid(trans_obj);
>> });
>>
>> ^ This is where the delay happens. I suggest launching the grid instantly
>> behind the $spinner_el and remove the $spinner_el when the transaction id
>> is recieved and set via self.
>>
>> There are two primary hindrances to doing this, one being the transaction
>> id being used as a url param in new tab mode,
>>
>> var url_params = {
>> 'trans_id': trans_obj.gridTransId, // <<---- HERE
>> 'is_query_tool': trans_obj.is_query_tool,
>> 'editor_title': titileForURLObj.title,
>> },
>> baseUrl = url_for('datagrid.panel', url_params) +
>> '?' + 'query_url=' + encodeURI(trans_obj.sURL) +
>> '&server_type=' + encodeURIComponent(trans_obj.server_type) +
>> '&server_ver=' + trans_obj.serverVersion+
>> '&fslashes=' + titileForURLObj.slashLocations;
>>
>> The other being this close handler,
>>
>> queryToolPanel.on(wcDocker.EVENT.CLOSED, function() {
>> $.ajax({
>> url: url_for('datagrid.close', {'trans_id': trans_obj.gridTransId}), //
>> <<---- and HERE
>> method: 'DELETE',
>> });
>> });
>>
>> Looking at the python server, this id is nothing but a random number
>> between 1 and 9999999,
>> # Create a unique id for the transaction
>> trans_id = str(random.randint(1, 9999999))
>>
>> So instead of generating this id once the connection to the database has
>> been established, I suggest generating a random number in javascript and
>> POSTing it to the backend to be associated with the newly created
>> connection asynchronously while the query tool loads in the background. The
>> spinning indicator can be removed once the server sends an OK response once
>> the connection is established and associated with the number POSTed.
>>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>