Re: Caching query plan costs - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Caching query plan costs
Date
Msg-id 20180903183335.GE25700@momjian.us
Whole thread Raw
In response to Re: Caching query plan costs  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Caching query plan costs  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: A strange GiST error message or fillfactor of GiST build
Next
From: Tom Lane
Date:
Subject: Re: Out arguments name of "pg_identify_object_as_address" function in 9.5.14 and 11beta3