It seems that with prepared statements (possibly not only prepared statements), "PostgreSQL has a built-in heuristics form statements whose plans can be cached: it plans them with the actual parameter values for the first 5 times, and then it switches to a generic plan if that plan promises not to perform worse. Unfortunately the generic plan doesn't keep the promise in this case." (source here: https://dba.stackexchange.com/questions/289130/postgresql-changes-same-query-plan-at-runtime) So, in my case it's possible that PG takes into account the actual value of the

timestamp

parameter for the first 5 execution: that'll be fast. From the 6th execution onwards, it doesn't consider what value

timestamp

actually has and always applies a generic query plan: this generic query plan is much much slower for the values of

timestamp

we actually use