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
|
Список | 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 по дате отправления: