Re: [pgadmin4] Explain plans

Hi

On Fri, Jan 19, 2018 at 2:09 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.
>
> 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
>
> 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
>
> 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?

"If explain plan takes to long to generate we will be waiting for it
in the foreground instead of polling" seems like a show stopper for
option 1 to me. Consider that the user may have chosen to do EXPLAIN
ANALYZE, which executes the actual query.

I agree that 3 isn't really an option - and I also agree that
factoring out functionality into smaller units is good. Option 2
doesn't preclude that though does it? It just doesn't require it.

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

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