> On 15 Dec 2023, at 22:49, Merlin Moncure <mmonc...@gmail.com> wrote: > > On Mon, Sep 11, 2023 at 11:07 PM David Rowley <dgrowle...@gmail.com > <mailto:dgrowle...@gmail.com>> wrote: >> Snip >> I took a few minutes to reverse engineer the tables in question (with >> assistance from an AI bot) and ran the query in question. >> Unsurprisingly, I also see planning as slower than execution, but with >> a ratio of about planning being 12x slower than execution vs the >> reported ~18x. >> >> Planning Time: 0.581 ms >> Execution Time: 0.048 ms >> >> Nothing alarming in perf top of executing the query in pgbench with -M >> simple. I think this confirms the problem is just with expectations. > > Yep. Very fast executing queries often have faster execution than plan > times. Postgres has a really dynamic version of SQL, for example, operator > overloading for example, which probably doesn't help things. This is just > the nature of SQL really. To improve things, just use prepared statements -- > that's why they are there.
Just to add my 2 cents: use prepared statements and - when applicable force generic plans: https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-PLAN-CACHE-MODE — Michal
