[*] improve single query details pg dashboard

[Bishoywadea]

Description

based on @0xgouda request this PR modify queries in single query dashboard in pg to match the updates in correspond prom dashboard and partially solves #1152 in this dashboard

fixes partially: #1152

AI & Automation Policy

• I am the human author and take full personal responsibility for every change in this PR.
• I have disclosed all tool(s) below.

AI/automation tools used (leave blank if none):

No agents were used in this PR i only used Gemini the free tier to help me with the queries but i have reviewed it carefully and tested it well

Checklist

• Code compiles and existing tests pass locally.
• New or updated tests are included where applicable.
• Documentation is updated where applicable.

[0xgouda]

Can you please attach a clear description of the approach you took for fixing the queries?

[Bishoywadea]

@0xgouda
i have solved it using the approach you mentioned in the #1152, by making CTE that get the last row from before the begining of that time range by selecting only time from stat_statments where dbname and query_id matched and the time is less than the begining of the range then sort them desc and get the first one
then replaced the $__timeFilter() with

time >= (SELECT time FROM baseline)
AND time <= $__timeTo()::timestamptz

by this modification i get another extra row for the first row in the required time range which make lag() not getting null for the first row
another thing i have modified queries to be /second and bytes instead of blocks units like in prom dashboard as per our conversation on slack

[Bishoywadea]

ping @0xgouda

[0xgouda]

@Bishoywadea
I believe we should use nullif(extract(epoch from sum(time - time_lag)), 0) instead of the places where we have nullif(extract(epoch from '$agg_interval'::interval), 0).

As this would cause the very last time group to output incorrect values, as it will have less than the number of expected data points (as they are still being collected), for example

See the drop at the end here and how it affects the Min field:

vs if we used nullif(extract(epoch from sum(time - time_lag)), 0):

As it won't add extra minutes in the divisor for the points that haven't been collected yet.

---

Also, I get why you did that, for performance, but I hope that pg will be able to handle the additional lag() efficiently as we are already calculating it for a previous column

[Bishoywadea]

@0xgouda makes sense, i think this is more accurate indeed, check it after the commit

[0xgouda]

LGTM, Good Job!