Horton

Re: PG 12 draft release notes

Haribabu Kommi <kommi.haribabu@gmail.com>

View thread
From: Haribabu Kommi <kommi.haribabu@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Bruce Momjian <bruce@momjian.us>, Andrew Gierth <andrew@tao11.riddles.org.uk>, Emre Hasegeli <emre@hasegeli.com>, Tomas Vondra <tv@fuzzy.cz>, Peter Geoghegan <pg@bowt.ie>, Alexander Korotkov <aekorotkov@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>, Surafel Temesgen <surafel3000@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-05-21T07:10:15Z
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

On Tue, May 21, 2019 at 8:17 AM Andres Freund <andres@anarazel.de> wrote:

>
>       <para>
>        Add <xref linkend="sql-create-access-method"/> command to create
>        new table types (Haribabu Kommi, Andres Freund, Álvaro Herrera,
>        Dimitri Dolgov)
>       </para>
>
> A few points:
>
> 1) Is this really source code, given that CREATE ACCESS METHOD TYPE
>    TABLE is a DDL command, and USING (...) for CREATE TABLE etc is an
>    option to DDL commands?
>

+1

It would be better to provide a description of the newly added syntax.
Do we need to provide any 'Note' explaining that currently there are no
other
alternatives to the heap?


2) I think the description sounds a bit too much like it's about new
>    forms of tables, rather than their storage. How about something
>    roughly like:
>
>    Allow different <link linkend="tableam">table access methods</> to be
>    <link linkend="sql-create-access-method>created</> and <link
>    linkend="sql-createtable-method">used</>. This allows to develop and
>    use new ways of storing and accessing table data, optimized for
>    different use-cases, without having to modify
>    PostgreSQL. The existing <literal>heap</literal> access method
>    remains the default.
>
> 3) This misses a large set of commits around making tableam possible, in
>    particular the commits around
>
> commit 4da597edf1bae0cf0453b5ed6fc4347b6334dfe1
> Author: Andres Freund <andres@anarazel.de>
> Date:   2018-11-16 16:35:11 -0800
>
>     Make TupleTableSlots extensible, finish split of existing slot type.
>
>    Given that those commits entail an API break relevant for extensions,
>    should we have them as a separate "source code" note?
>

+1 to add, but I am not sure whether we need to list all the breakage that
has introduced by Tableam needs to be described separately or with some
combined note to explain it to extension developers is fine?



> 4) I think the attribution isn't quite right. For one, a few names with
>    substantial work are missing (Amit Khandekar, Ashutosh Bapat,
>    Alexander Korotkov), and the order doesn't quite seem right. On the
>    latter part I might be somewhat petty, but I spend *many* months of
>    my life on this.
>
>    How about:
>    Andres Freund, Haribabu Kommi, Alvaro Herrera, Alexander Korotkov,
> David Rowley, Dimitri Golgov
>    if we keep 3) separate and
>    Andres Freund, Haribabu Kommi, Alvaro Herrera, Ashutosh Bapat,
> Alexander Korotkov, Amit Khandekar, David Rowley, Dimitri Golgov
>    otherwise?


+1 to either of the above.
Without Andres enormous efforts, Tableam couldn't have been possible into
v12.


Regards,
Haribabu Kommi
Fujitsu Australia