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