Horton

Re: PG 12 draft release notes

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <bruce@momjian.us>
Cc: Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-05-21T21:00:31Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. doc: PG 12 relnotes: update wording on truncate/vacuum item

  2. docs: PG 12 relnotes, update btree items

  3. doc: PG 12 relnotes, list added snowball/FTS languages

  4. doc: PG 12 relnotes, merge new SQL partition function items

  5. docs: PG 12 release notes, support functions

  6. docs: PG 12 relnote adjustments based on feedback from Tom Lane

  7. docs: adjust RECORD PG 12 relnote item

  8. doc: adjust PG 12 relnotes item on float digit adjustment

  9. doc: adjustments for PG 12 release notes

  10. docs: fix duplicate wording in PG 12 release notes

  11. doc: properly attibute PG 12 pgbench release note item

  12. doc: PG 12 release notes: normalize attribution names

  13. Refactor the fsync queue for wider use.

  14. Add "split after new tuple" nbtree optimization.

  15. Add nbtree high key "continuescan" optimization.

  16. Allow amcheck to re-find tuples using new search.

  17. Consider secondary factors during nbtree splits.

  18. Partial implementation of SQL/JSON path language

  19. Allow extensions to generate lossy index conditions.

  20. Make TupleTableSlots extensible, finish split of existing slot type.

  21. Reduce path length for locking leaf B-tree pages during insertion

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.

> 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.

			regards, tom lane