On Mon, May 20, 2019 at 08:48:15PM -0400, Tom Lane wrote:
> Andres Freund <and...@anarazel.de> writes:
> > On 2019-05-20 18:56:50 -0400, Tom Lane wrote:
> >> I'm not sure which of my commits you want me to opine on, other than
>
> > That was one of the main ones. I'm also specifically wondering about:
>
> >> Author: Tom Lane <t...@sss.pgh.pa.us>
> >> 2019-02-09 [1fb57af92] Create the infrastructure for planner support
> >> functions.
> >> <para>
> >> Add support for <link linkend="sql-createfunction">function
> >> selectivity</link> (Tom Lane)
> >> </para>
> >> </listitem>
> >>
> >> Hm, that message doesn't seem like an accurate description of that
> >> commit (if anything it's a391ff3c?). Given that it all requires C
> >> hackery, perhaps we ought to move it to the source code section?
>
> 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.
Notice that there are some improvments in in-core functions. Should this
still be moved to the source code section?
> > and perhaps you could opine on whether we ought to include
>
> >> <listitem>
> >> <!--
> >> Author: Tom Lane <t...@sss.pgh.pa.us>
> >> 2019-02-11 [1d92a0c9f] Redesign the partition dependency mechanism.
> >> -->
> >>
> >> <para>
> >> Improve handling of partition dependency (Tom Lane)
> >> </para>
> >>
> >> <para>
> >> This prevents the creation of inconsistent partition hierarchies
> >> in rare cases.
> >> </para>
> >> </listitem>
>
> It's probably worth mentioning, but I'd say something like
>
> Fix bugs that could cause ALTER TABLE DETACH PARTITION
> to not drop objects that should be dropped, such as
> automatically-created child indexes.
>
> The rest of it is not terribly interesting from a user's standpoint,
> I think.
Done.
--
Bruce Momjian <br...@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 +
