Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qBGgq-00043e-Aj for pgadmin-hackers@arkaria.postgresql.org; Mon, 19 Jun 2023 15:21:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1qBGgp-0008U8-4V for pgadmin-hackers@arkaria.postgresql.org; Mon, 19 Jun 2023 15:21:11 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qBGgo-0008Tz-Tb for pgadmin-hackers@lists.postgresql.org; Mon, 19 Jun 2023 15:21:10 +0000 Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qBGgm-003Rf2-4m for pgadmin-hackers@postgresql.org; Mon, 19 Jun 2023 15:21:10 +0000 Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-51a200fc3eeso4951405a12.3 for ; Mon, 19 Jun 2023 08:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; t=1687188067; x=1689780067; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HmB6kv3a6tf5T165YSuMwfR1Rz7krc0eTI25TM/2MVU=; b=nK0LL0yU7CfrKyiNEsEcKjU+NDxxr23R5t7SiXI95iwRD4aNZRFzmAkyDk7bhZ9tyz GuQYQnrz9SlpEN2CCQUGnwmW2T2HhXw/D4QqRfyueOex+LRoEWJkdRI/eQs76TSeNVCo 74vf5q1bGdYllv9tTf32t8+NXzPaMS445FECKQKzAB+LxLTVIUb5aknEL3VZpTiLkgkB tioNf0SL0DLDGkbD21tEEizv+l0tqEXKzE5AGIR+6HwXnNEvD/AcxRex9LTiVYXeJH10 vmehA9Kr3q9f0/LA7pWRgu3oeksJGqPiKN0X6X/l3xx2hPMOqxGKnTyMMCP0j4htnlDg Kpug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687188067; x=1689780067; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HmB6kv3a6tf5T165YSuMwfR1Rz7krc0eTI25TM/2MVU=; b=dlPgXBvTQB3gdDVBLL//aUKTMhfXXpkAPBlN+qkGmbothH69+cIOWJvSccgV8Rth4R 8mHU8xyWyKsYsTSr9digLtzf1lW09ApwSbhCUrJNCKDfiOT49LhVLhMrMyhuYFiKx/pg ouKI+KJXslBeUQIlYFNvivRzxkBWD0bPQv7XzjQ3Dda6ahPiryOK5v8uymwFL/6BetdG Fvaa3CqP02vcr7nKc7HVfIwqXULumxRSIaaRq1qq/0K6WYY8Or/OHFp1xJvmWDhQJcbW K0lcGi6vvdoZ0zOyFVvyUPqMAWT7Rx06cLToecQVFjcLXr5T7uERLcL0rTAIGuObR9ZP 8PKA== X-Gm-Message-State: AC+VfDzVzdQqdYUItHlPPMJiripH3VVLxBY71cW9z3CB3nbcGswvilIz Ly3PMaBzzHMU3p29OBegZcsV1kYMTsjCkAOJIJPMUA== X-Google-Smtp-Source: ACHHUZ4nByae2nHHuosVdkwxuxrFD4bwDOCf4dd4Yvx0R0AFFH6AGH4ogaqW1lzN9rhJLUSF1nc3aGvYRFv/8lSurEc= X-Received: by 2002:a17:907:6d1d:b0:988:de4b:9d09 with SMTP id sa29-20020a1709076d1d00b00988de4b9d09mr1375282ejc.10.1687188067221; Mon, 19 Jun 2023 08:21:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Mon, 19 Jun 2023 16:20:55 +0100 Message-ID: Subject: Re: Pgadmin4 System Stats Extension Design To: Sahil Harpal Cc: Aditya Toshniwal , Akshay Joshi , pgadmin-hackers@postgresql.org, Khushboo Vashi Content-Type: multipart/alternative; boundary="0000000000006a984605fe7d15ff" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000006a984605fe7d15ff Content-Type: text/plain; charset="UTF-8" On Mon, 19 Jun 2023 at 16:11, Sahil Harpal wrote: > On Mon, 19 Jun 2023 at 14:07, Dave Page wrote: > >> >> Seems reasonable to me. A wireframe would seem like the best next step, >> to confirm we're all happy with what's proposed. It's hard to visualise >> from a list of bullet points. >> > > Hi all, > > I am attaching the updated wireframes. > Hi, It's not quite what I was suggesting - you have Read for 4 disks on one graph, and Write for 4 on another etc. (and then total reads and writes separately for each disk). I was suggesting one graph per disk (as you did for reads/writes) for each pair of read/write metrics. I'd aim for 3 graphs per row on a normal display (Total Reads/Total Writes, Bytes Read/Bytes Written, Time Reading/Time Writing), and 1 for small displays (never 2, as that will always look unbalanced). As Ashesh noted, you should also omit the "Sys" part of the names (and various other labels will need to be cleaned up), but there's no need to do that on the wireframe. -- Dave Page Blog: https://pgsnake.blogspot.com Twitter: @pgsnake EDB: https://www.enterprisedb.com --0000000000006a984605fe7d15ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, 19 Jun 2023 at 16:11, Sahil H= arpal <sahilharpal1234@gmai= l.com> wrote:
On Mon, 19 Jun 2023 at 14:07, Dave Page <dpage@pgadmin.org> wrote:

Seems reasonable to me. A wirefra= me would seem like the best next step, to confirm we're all happy with = what's proposed. It's hard to visualise from a list of bullet point= s.

Hi all,

=
I am attaching the updated wireframes.

Hi,

It's not quite wh= at I was suggesting - you have Read for 4 disks on one graph, and Write for= 4 on another etc. (and then total reads and writes separately for each dis= k). I was suggesting one graph per disk (as you did for reads/writes) for e= ach pair of read/write metrics.=C2=A0

I'd aim = for 3 graphs per row on a normal display (Total Reads/Total Writes, Bytes R= ead/Bytes Written, Time Reading/Time Writing), and 1 for small displays (ne= ver 2, as that will always look unbalanced).

As As= hesh noted, you should also omit the "Sys" part of the names (and= various other labels will need to be cleaned up), but there's no need = to do that on the wireframe.

--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake<= br>
EDB: http= s://www.enterprisedb.com

--0000000000006a984605fe7d15ff--