Optimizing competitor kpis #89
Conversation
…es largely the speed of the query
| on | ||
| date_trunc('minute', block_time) = p0.timestamp | ||
| p0.timestamp = date_trunc('day', case when ('{{end_time}}' = '2100-01-01' or date('{{end_time}}') = date_trunc('day', now())) then now() - interval '1' day else date('{{end_time}}') end) |
There was a problem hiding this comment.
this logic seems unnecessarily complex. Isn't this the same as
least(date('{{end_time}}'), now() - interval '1' day)
There was a problem hiding this comment.
Also please document the new parameter
| and p0.timestamp >= date_add('day', -1, (case when '{{competitor_end_time}}' = '2100-01-01' then now() else timestamp '{{competitor_end_time}}' end)) | ||
| and p0.timestamp <= (case when '{{competitor_end_time}}' = '2100-01-01' then now() else timestamp '{{competitor_end_time}}' end) |
There was a problem hiding this comment.
Maybe using
p0.timestamp between date_add('day', -1, least('{{competitor_end_time}}', now())) and least('{{competitor_end_time}}', now())
is slightly easier to read? Also I'm not sure if reducing the range to now() is actually making the query more effective (since there are no datapoints beyond now the full table scan should complete in the same time)
There was a problem hiding this comment.
Good idea!
About the now(), the query is built to only search for 24 hours, so the upper bound is meant to backfill the data base
…to end (more intuitive) as we are talking about dates
|
I changed the parameter from end_time to start_time, as it makes more sense when rounding to a date |
Updated the queries to fit the new table prices.minute to use them more efficiently.
For total TVL, switched to the table prices.day: less expensive and gets an average over the time frame for the study