Re: [pgadmin4] Explain plans

On Fri, Jan 19, 2018 at 7:39 PM, Joao De Almeida Pereira <
jdealmeidapereira(at)pivotal(dot)io> wrote:

> Hello Hackers,
> We are trying to find a solution for the explain plans that currently are
> not working in GP, due to the lack of support for JSON. We believe that the
> best options for this it would be to display the text in the tab instead of
> the visual version for our case.
> In order to implement this we came up with some options that we would like
> to understand what the community think about them.
>
>
> 1.
>
> Move the SQL to generate explain plans to backend
> For this approach we would create a new endpoint to generate an
> explain plan and when we click the explain plan buttons instead of doing a
> new SQL query we would call the new endpoint and wait for the explain plan
> to be generated
> - Pros:
> - All SQL related code is in the backend
> - Extract more code from SQLEditor into smaller and more
> testable/maintainable modules
> - Cons:
> - Major Revamp of SQLEditor
> - If explain plan takes to long to generate we will be waiting
> for it in the foreground instead of polling
>
>
​+1

We can make it configurable to work with both PG (text & json) & GP (text).
With the current implementation the constraint we have is that snapsvg
<http://snapsvg.io/> library which we use to draw the explain plan do not
support any other format except JSON.
​

>
> 1.
>
> Add parameters while executing SQL
> If we add parameters in the SQL query request we send to the backend,
> informing the backend that the SQL query is a Explain Plan to be
> executed(The response can have a flag saying that this is an explain plan,
> instead of assuming from the return values that it was an explain plan)
> - Pros:
> - All SQL related code is in the backend
> - Leverage the current polling system
> - Cons:
> - Add more logic to an already complex SQLEditor
> 2.
>
> Disable Explain plan buttons
> Disable/Enable the Explain plan buttons depending on the type of
> database, this would also include the tab in the bottom of the SQLEditor
> - Pros:
> - Simpler solution
> - Cons:
> - Not really a good implementation, because all databases
> support explain plans
> - There will still be SQL in both frontend and backend
> - Looks more like a temporary fix instead of a solution
>
>
> We believe that we should not keep build feature inside the SQLEditor, but
> should try to extract as many parts of it as possible, this is where the
> current option 2 fall short in our point of view. Due to this we believe
> that option 1 looks promising and that is that path that we prefer to go
> into.
> What does the community think about this?
>
> Thanks
> Joao
>