Re: Planning time is time-consuming

> On 15 Dec 2023, at 22:49, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>
> On Mon, Sep 11, 2023 at 11:07 PM David Rowley <dgrowleyml(at)gmail(dot)com <mailto:dgrowleyml(at)gmail(dot)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