Re: PG 12 draft release notes - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: PG 12 draft release notes
Date
Msg-id 20190522152121.46i7p63dhlk46qyq@momjian.us
Whole thread Raw
In response to Re: PG 12 draft release notes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, May 21, 2019 at 05:00:31PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > On Mon, May 20, 2019 at 08:48:15PM -0400, Tom Lane wrote:
> >> Yes, this should be in "source code".  I think it should be merged
> >> with a391ff3c and 74dfe58a into something like
> >> 
> >> Allow extensions to create planner support functions that
> >> can provide function-specific selectivity, cost, and
> >> row-count estimates that can depend on the function arguments.
> >> Support functions can also transform WHERE clauses involving
> >> an extension's functions and operators into indexable clauses
> >> in ways that the core code cannot for lack of detailed semantic
> >> knowledge of those functions/operators.
> 
> > The new text is:
> 
> >         Add support function capability to improve optimizer estimates
> >         for functions (Tom Lane)
> 
> >         This allows extensions to create planner support functions that
> >         can provide function-specific selectivity, cost, and row-count
> >         estimates that can depend on the function arguments.  Also, improve
> >         in-core estimates for <function>generate_series()</function>,
> >         <function>unnest()</function>, and functions that return boolean
> >         values.
> 
> Uh ... you completely lost the business about custom indexable clauses.
> I agree with Andres that that's the most important aspect of this.

Oh, I see what you mean now. I have updated the docs and moved the item
to Source Code:

       <para>
        Add support function capability to improve optimizer estimates,
        inlining, and indexing for functions (Tom Lane)
       </para>

       <para>
        This allows extensions to create planner support functions that
        can provide function-specific selectivity, cost, and row-count
        estimates that can depend on the function's arguments.  Support
        functions can also supply simplified representations and index
        conditions, greatly expanding optimization possibilities.
       </para>

> > Notice that there are some improvments in in-core functions. Should this
> > still be moved to the source code section?
> 
> I doubt that that's worth mentioning at all.  It certainly isn't a
> reason not to move this to the source-code section, because that's
> where we generally put things that are of interest for improving
> extensions, which is what this mainly is.

In-core function mention removed.

-- 
  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: Robert Haas
Date:
Subject: Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3
Next
From: Andres Freund
Date:
Subject: Re: "long" type is not appropriate for counting tuples