Horton

Re: WIP: Covering + unique indexes.

Anastasia Lubennikova <a.lubennikova@postgrespro.ru>

View thread View on postgr.es
From: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>, pgsql-hackers@lists.postgresql.org, Anastasia Lubennikova <lubennikovaav@gmail.com>
Date: 2018-01-30T14:09:13Z
Lists: pgsql-hackers

Attachments

26.01.2018 07:19, Thomas Munro:
> On Fri, Jan 26, 2018 at 3:01 AM, Anastasia Lubennikova
> <a.lubennikova@postgrespro.ru> wrote:
>> Thanks for the reminder. Rebased patches are attached.
> This is a really cool and also difficult feature.  Thanks for working
> on it!  Here are a couple of quick comments on the documentation,
> since I noticed it doesn't build:
>
> SGML->XML change: (1) empty closing tags "</>" are no longer accepted,
> (2) <xref ...> now needs to be written <xref .../> and (3) xref IDs
> are now case-sensitive.
>
> +  PRIMARY KEY ( <replaceable
> class="parameter">column_name</replaceable> [, ... ] ) <replaceable
> class="parameter">index_parameters</replaceable> <optional>INCLUDE
> (<replaceable class="parameter">column_name</replaceable> [,
> ...])</optional> |
>
> I hadn't seen that use of "<optional>" before.  Almost everywhere else
> we use explicit [ and ] characters, but I see that there are other
> examples, and it is rendered as [ and ] in the output.  OK, cool, but
> I think there should be some extra whitespace so that it comes out as:
>
>    [ INCLUDE ... ]
>
> instead of:
>
>    [INCLUDE ...]
>
> to fit with the existing convention.
>
> +        ... This also allows <literal>UNIQUE</> indexes to be defined on
> +        one set of columns, which can include another set of columns in the
> +       <literal>INCLUDE</> clause, on which the uniqueness is not enforced.
> +        It's the same with other constraints (PRIMARY KEY and
> EXCLUDE). This can
> +        also can be used for non-unique indexes as any columns which
> are not required
> +        for the searching or ordering of records can be used in the
> +        <literal>INCLUDE</> clause, which can slightly reduce the
> size of the index.

Thank you for reviewing. All mentioned issues are fixed.

-- 
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Commits

  1. Adjust INCLUDE index truncation comments and code.

  2. Add commentary explaining why MaxIndexTuplesPerPage calculation is safe.

  3. Indexes with INCLUDE columns and their support in B-tree

  4. Add amcheck verification of heap relations belonging to btree indexes.

  5. Doc: move info for btree opclass implementors into main documentation.

  6. Doc: mention that you can't PREPARE TRANSACTION after NOTIFY.

  7. Remove dedicated B-tree root-split record types.

  8. Restructure index access method API to hide most of it at the C level.

  9. Split _bt_insertonpg to two functions.

  10. Major overhaul of btree index code. Eliminate special BTP_CHAIN logic for