Spring Data JPA Pagination Queries and HikariCP Connection Pool Utilization in JHipster

When using Spring Data JPA's Pageable interface in a JHipster-generated service, each pagination request triggers two SQL statements: a data query with LIMIT/OFFSET and a separate count query to determine the total number of rows.

Under concurrent load, the count query can occupy a connection for the duration of its execution, especially on large tables lacking appropriate indexes, while the data query may also hold a connection if the transaction remains open waiting for downstream calls.

Given that HikariCP's maximum‑pool‑size is fixed in application.yml and that different SQL dialects generate slightly different count‑query plans, it is unclear whether the observed intermittent connection‑pool exhaustion stems primarily from the count query, the data query, or a combination of both.

What proportion of active connections is attributable to the count query versus the data query during peak pagination traffic?
Does adding a covering index for the count query significantly reduce connection hold time?
Should the service layer explicitly separate the count and data queries into different transactions to limit connection usage?