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
