From: | Joao De Almeida Pereira <jdealmeidapereira(at)pivotal(dot)io> |
---|---|
To: | pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org> |
Subject: | [pgadmin4] Explain plans |
Date: | 2018-01-19 14:09:22 |
Message-ID: | CAE+jjammFx-+g40r2kWOJKfEVJoLtp0b=xJj6yJkXsUsPcMK9Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-hackers |
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
2.
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
3.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Murtuza Zabuawala | 2018-01-20 06:04:11 | Re: [pgadmin4] Explain plans |
Previous Message | Joao De Almeida Pereira | 2018-01-19 12:56:32 | Re: [pgadmin4][Patch]: Display Functions node for GreenPlum database |