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.