issue_comments: 970780866

This data as json

html_url issue_url id node_id user created_at updated_at author_association body reactions issue performed_via_github_app
https://github.com/simonw/datasette/issues/1513#issuecomment-970780866 https://api.github.com/repos/simonw/datasette/issues/1513 970780866 IC_kwDOBm6k_c453PDC 9599 2021-11-16T23:01:57Z 2021-11-16T23:01:57Z OWNER

One disadvantage to this approach: if you have a SQL time limit of 1s and it takes 0.9s to return the rows but then 0.5s to calculate each of the requested facets the entire query will exceed the time limit.

Could work around this by catching that error and then re-running the query just for the rows, but that would result in the user having to wait longer for the results.

Could try to remember if that has happened using an in-memory Python data structure and skip the faceting optimization if it's caused problems in the past? That seems a bit gross.

Maybe this becomes an opt-in optimization you can request in your metadata.json setting for that table, which massively increases the time limit? That's a bit weird too - now there are two separate implementations of the faceting logic, which had better have a REALLY big pay-off to be worth maintaining.

What if we kept the query that returns the rows to be displayed on the page separate from the facets, but then executed all of the facets together using this method such that the cte only (presumably) has to be calculated once? That would still lead to multiple facets potentially exceeding the SQL time limit when single facets would not have.

Maybe a better optimization would be to move facets to happening via fetch() calls from the client, so the user gets to see their rows instantly and the facets then appear as and when they are available (though it would cause page jank).

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
 1055469073