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 <dp...@pgadmin.org> wrote: > Hi > > On Fri, Jan 19, 2018 at 2:09 PM, Joao De Almeida Pereira > <jdealmeidapere...@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 >
