Обсуждение: [pgadmin4] Explain plans
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
- Pros:
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
- Pros:
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
- Pros:
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
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
+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 library which we use to draw the explain plan do not support any other format except JSON.
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?ThanksJoao
On Jan 20, 2018 11:34 AM, "Murtuza Zabuawala" <murtuza.zabuawala@enterprisedb.com> 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
+1We can make it configurable to work with both PG (text & json) & GP (text).With the current implementation the constraint we have is that snapsvg library which we use to draw the explain plan do not support any other format except JSON.
snapsvg has nothing to do with JSON plan.
snapsvg has nothing to do with JSON.
We choose JSON based plan to avoid unnecessary parsing errors with the TEXT based plans.
--
Thanks,
Ashesh Vashi
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?ThanksJoao
Hi On Fri, Jan 19, 2018 at 2:09 PM, Joao De Almeida Pereira <jdealmeidapereira@pivotal.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
Hello,
Eventually we can extract a ExecuteQuery class that will execute the query and poll for the result this way can extract some code from SQLEditor. Then the execute query can have parameters for the explain plan option and we can build the query in the backend.
Thanks for the input, I will try to do some work in this extraction.
Thanks
Joao
On Mon, Jan 22, 2018 at 4:58 AM, Dave Page <dpage@pgadmin.org> wrote:
Hiin the foreground instead of polling" seems like a show stopper for
On Fri, Jan 19, 2018 at 2:09 PM, Joao De Almeida Pereira
<jdealmeidapereira@pivotal.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
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