Learn how to simulate latency when working with PostgreSQL and Hibernate. What’s more, learn how to do it via JDBC and jOOQ.
Join the DZone community and get the full member experience. I’ve run across a fun little trick to simulate latency in your development environments when testing some SQL queries. Possible use-cases including to validate that backend latency won’t bring down your frontend, or that your UX is still bearable, etc. The solution is PostgreSQL and Hibernate specific, though it doesn’t have to be. Besides, it uses a stored function to work around the limitations of a VOID function in PostgreSQL, but that can be worked around differently as well, without storing anything auxiliary to the catalog. To remove the Hibernate dependency, you can just use the pg_sleep function directly using a NULL predicate, but don’t try it like this! This will sleep 1 second per row (!). As can be seen in the explain plan. Let’s limit to 3 rows to see: And the result is: As you can see, the whole query took about 3 seconds for 3 rows. In fact, this is also what happens in Gunnar’s example from the tweet, except that he was filtering by ID, which “helps” hide this effect. We can use what Oracle calls scalar subquery caching, the fact that a scalar subquery can be reasonably expected to be side-effect free (despite the obvious side-effect of pg_sleep), meaning that some RDBMS cache its result per query execution.
