Re: Caching query plan costs

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Caching query plan costs
Дата
Msg-id 20180903183335.GE25700@momjian.us
обсуждение исходный текст
Ответ на Re: Caching query plan costs  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Caching query plan costs  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Mon, Sep  3, 2018 at 01:30:33PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > What if we globally or locally cache the _cost_ of plans, so we can
> > consult that cache before planning and enable certain optimizations?
> 
> But what would you use as cache key?  And how's this help if we haven't

Uh, I assume we would do what pg_stat_statements does and remove the
constants an hash that.

> seen a similar query before in the session?

Well, if it was global we could use output from another session.

I guess my point is that this only used to turn on micro-optimizations
and maybe parallelism and JIT, so it doesn't have to be 100% accurate.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


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

Предыдущее
От: Andrey Borodin
Дата:
Сообщение: Re: A strange GiST error message or fillfactor of GiST build
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Out arguments name of "pg_identify_object_as_address" function in 9.5.14 and 11beta3