Re: Proposal Dashboard design for system of pgadmin

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Kunal Garg <gargkunal02(at)gmail(dot)com>
Cc: Ashesh Vashi <ashesh(dot)vashi(at)enterprisedb(dot)com>, pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Proposal Dashboard design for system of pgadmin
Date: 2022-06-27 08:29:23
Message-ID: CA+OCxow=uQ03Uzgo+=0VXFdGY27dhO8DsqKrHGcxH79SZeKEPw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

Hi

On Sun, 26 Jun 2022 at 12:40, Kunal Garg <gargkunal02(at)gmail(dot)com> wrote:

> Plan:-
>
> To integrate a detailed view of system activity into the existing pgAdmin
> dashboard following a consistent design that matches the existing UI/UX and
> meets User Acceptance Testing Standards.
>
> Proposed Layout Design:-
>
>
>
>
Some initial thoughts on what you propose to display:

- OS Uptime should not be a graph. It's not overly useful, and will just
trend upwards linearly before resetting to zero if there's a restart. Just
make it a text label.

- Thread count is probably less important than process count on a
PostgreSQL server. I would probably show both, in a small chart as those
are values that do change over time in response to system activity.

- I would put the "system info" data (Host name, architecture, kernel,
thread/process count etc) at the top as it's what you might consider
overview or meta data. Then have the rest of the info below that, probably
2 full width columns with two rows for CPU, memory, disk, and network.

- Consider what to display if there are multiple NICs on the system.

- Consider what to display if there are multiple disks on the system - and
there alway will be on a Linux machine for example. Many of them will be
hidden here (e.g. /proc, /sys, tmpfs's), whilst others should be displayed.
We cannot assume stats on only one disk are important, as the system might
be configured with tablespaces or the WAL on different devices.

Data fetched from queries:-
>
> Details of different queries will be shown on a given component/card as
> shown in the design.
>

<snip data source info - that's more an implementation detail at this stage>

>
>
> Impact on the existing layout:-
>
> Existing layout will remain the same for most of the part. Here are some
> options for showing the system stats dashboard option to the users.
>
>
>
>
>
>
>
>
>
> 1.
>
> New button for system statistics on the Dashboard Navbar (refer to the
> red box in the image for the location of this button)
>
>
>
> UI impact when the system_stats extension is not present in the PostgreSQL
> instance:
>
> The page will open as usual with the following message,
>
> “No system statistics information is available for the selected object”
>
>
>
> 1.
>
> On hovering over the Dashboard tab, a dropdown will come, giving the
> user an option to select either the already existing pgadmin dashboard or
> the system statistics dashboard. (refer to the green box in the image
> for the location of this button)
>
>
>
> UI impact when the system_stats extension is not present in the PostgreSQL
> instance:
>
> This will happen only when the user has not selected any server, then the
> dashboard will open as usual as shown in the image.
>
>
>
> 1.
>
> On Selecting the Dashboard tab, 2 new buttons will be displayed under
> the dashboard tab, clicking any one will show the respective dashboard.
> (refer to the blue box in the image for the location of this button)
>
>
>
> UI impact when the system_stats extension is not present in the PostgreSQL
> instance:
>
> This will happen only when the user has not selected any server, then the
> dashboard will open as usual as shown in the image
>
>
>
> Note: The dashboards are contextual, they're dependent on the node
> selected on the left-hand side tree, that is, the values change as per the
> server node selected. Similarly, the system statistics dashboard will also
> be contextual and change with the selected server.
>

I'm 90% sure I wouldn't want to see an additional dashboard (option 1), and
option 3 would almost certainly require modifying the wcDocker library
which I think is a bad idea. I would consider how to accommodate the
additional information on the existing dashboard. A couple of ideas:

1) Move all the existing elements and the new elements into collapsible
horizontal regions. Then you can display as much or as little as the user
wants. This is essentially how it would work in Grafana.

2) Add sub tabs inside the dashboard. If (and only if) system_stats is
present on a server, have a top-level tabset within the dashboard with tabs
for "Database Info" (with the existing display) and "System Info". By
default, the user is shown what they see now, but they can click the System
Info tab to see that data. Remember the user's choice, so the same tab can
be displayed first in the future. This is essentially your option 3, but
using tabsets instead of buttons.

>
>
>
>
> Filters available in the preferences:-
>
> Under the files tab -> Preferences
>
> In preferences there are multiple dropdowns for different parts of the
> dashboard, giving the user power to customize the dashboard as per their
> need by enabling or disabling certain graphs and changing the refresh rate
> of the graphs.
>
> In the preferences tab, there is a drop-down by the name of “dashboard”,
> which gives 2 options for selecting “graphs” and “display”. A similar
> layout will be followed for the “system statistics” dashboard.
>

Yes.

Thanks!

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message Khushboo Vashi 2022-06-27 08:37:09 Re: Proposal Dashboard design for system of pgadmin
Previous Message Nikhil Mohite 2022-06-27 08:25:34 Re: [pgAdmin][RM-6132]: [React] Port debugger to React