Pagination for aggregation queries

[Pierlou]

Pagination for aggregation queries is currently broken, because we are getting the total number of rows based on the Content-Range that is returned by postgrest, which describes the total number of rows in the table, whereas we are looking for the number of rows in the requested aggregation.
Examples:

• ?birth__less=1980 has the right Content-Range
• ?birth__groupby&birth__count gives a total of 1000 rows (the number of rows of the unfiltered table)
• ?birth__groupby&birth__count&score__less=0.3 gives the same total as ?score__less=0.3

We are not getting the total number of rows for the aggregated query unless we don't specify the offset and count the number of results "manually", which would mean another (aggregation) query for each aggregation query. Do we actual need the total in these cases?
For now the considered patch is:

• to stop displaying the (wrong) total for aggregation queries
• to slightly refactor the way we compute the next_page

[maudetes]

I guess we should follow this PostgREST issue for a better solution in a second iteration.

[Pierlou]

Thanks for the reference, I didn't manage to find if there was an open topic for this! We'll keep this issue open as a reminder to regularly check if there's a fix