Closed haneslinger closed 2 months ago
Label error. Requires at least 1 of: Feature, Bug, Enhancement, Maintenance, Documentation, Performance, Do not publish. Found:
Label error. Requires at least 1 of: Feature, Bug, Enhancement, Maintenance, Documentation, Performance, Do not publish. Found:
documenting the current plan for this ticket: awaiting feedback from @ebeers-png. Otherwise we will go with alt, deploy to dev2 and do some testing there with orgs that have many extra data fields.
I updated this to only need 1 query for extra_data columns, and 1 query for canonical columns, resulting in an 8.7x speed up over the improvements that Hannah already implemented. The number of queries has gone from 141 to 10 (4 of which are just overhead from the decorators).
In total, the stats request is now 35x faster than it used to be, and only takes 436ms to load for a large org.
Note
normalized_address
was incorrectly being returned in the results, now the results correctly match the columnsNumber of Extra Data Fields
count
IMPORTANT
the lastest commit,
alt
, is a version that'll only run quick when you're extra columns are sparely populated (i think), like on dev1, BPS- DC, cycle 2016. it's odd,the commit before that might be betteralot stuff we weren't using anymore, however, most improvement comes from rewriting the queries.
cuts it in half, but it still takes along time.
Far and away, the most expensive part it getting the count of states that have each column populated. I rewrote the query to be more DB heavy, which sped it up, but it's still rather expensive it runs this query for every column (diff column name, of course):
and this query for every extra data column:
now, while I dont think there's way around performing a group by for every column, I bet there a way to make a temporary table out of the bit they all share, the bit that gets the relevant states.
I just dont know how.