Re: Planning time is time-consuming

Поиск
Список
Период
Сортировка
От Michał Kłeczek
Тема Re: Planning time is time-consuming
Дата
Msg-id 6BA12ABC-ADDE-4949-8A81-25715E6A2108@kleczek.org
обсуждение исходный текст
Ответ на Re: Planning time is time-consuming  (Merlin Moncure <mmoncure@gmail.com>)
Список pgsql-performance


On 15 Dec 2023, at 22:49, Merlin Moncure <mmoncure@gmail.com> wrote:

On Mon, Sep 11, 2023 at 11:07 PM David Rowley <dgrowleyml@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

В списке pgsql-performance по дате отправления:

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: Planning time is time-consuming
Следующее
От: Jerry Brenner
Дата:
Сообщение: Which side of a Merge Join gets executed first? Do both sides always get executed?