Horton

Thread

Commits

  1. Document RelationGetIndexAttrBitmap better

  2. Ignore BRIN indexes when checking for HOT udpates

  1. pgsql: Ignore BRIN indexes when checking for HOT udpates

    Tomas Vondra <tomas.vondra@postgresql.org> — 2021-11-30T19:04:47Z

    Ignore BRIN indexes when checking for HOT udpates

When determining whether an index update may be skipped by using HOT, we
can ignore attributes indexed only by BRIN indexes. There are no index
pointers to individual tuples in BRIN, and the page range summary will
be updated anyway as it relies on visibility info.

This also removes rd_indexattr list, and replaces it with rd_attrsvalid
flag. The list was not used anywhere, and a simple flag is sufficient.

Patch by Josef Simanek, various fixes and improvements by me.

Author: Josef Simanek
Reviewed-by: Tomas Vondra, Alvaro Herrera
Discussion: https://postgr.es/m/CAFp7QwpMRGcDAQumN7onN9HjrJ3u4X3ZRXdGFT0K5G2JWvnbWg%40mail.gmail.com

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/5753d4ee320b3f6fb2ff734667a1ce1d9d8615a1

Modified Files
--------------
doc/src/sgml/indexam.sgml                        | 11 +++
src/backend/access/brin/brin.c                   |  1 +
src/backend/access/gin/ginutil.c                 |  1 +
src/backend/access/gist/gist.c                   |  1 +
src/backend/access/hash/hash.c                   |  1 +
src/backend/access/heap/heapam.c                 |  2 +-
src/backend/access/nbtree/nbtree.c               |  1 +
src/backend/access/spgist/spgutils.c             |  1 +
src/backend/utils/cache/relcache.c               | 50 ++++++++------
src/include/access/amapi.h                       |  2 +
src/include/utils/rel.h                          |  3 +-
src/include/utils/relcache.h                     |  4 +-
src/test/modules/dummy_index_am/dummy_index_am.c |  1 +
src/test/regress/expected/brin.out               | 85 ++++++++++++++++++++++++
src/test/regress/sql/brin.sql                    | 63 ++++++++++++++++++
15 files changed, 202 insertions(+), 25 deletions(-)

  2. Re: pgsql: Ignore BRIN indexes when checking for HOT udpates

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2023-08-09T09:11:55Z

    On 2021-Nov-30, Tomas Vondra wrote:

> Ignore BRIN indexes when checking for HOT udpates

I was trying to use RelationGetIndexAttrBitmap for something and
realized that its header comment does not really explain things very
well.  That was already the case before this commit, but it (this
commit) did add new possible values without mentioning them.  I propose
the attached comment-only patch.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
Al principio era UNIX, y UNIX habló y dijo: "Hello world\n".
No dijo "Hello New Jersey\n", ni "Hello USA\n".

  3. Re: pgsql: Ignore BRIN indexes when checking for HOT udpates

    Tomas Vondra <tomas.vondra@enterprisedb.com> — 2023-08-09T15:56:48Z

    On 8/9/23 11:11, Alvaro Herrera wrote:
> On 2021-Nov-30, Tomas Vondra wrote:
> 
>> Ignore BRIN indexes when checking for HOT udpates
> 
> I was trying to use RelationGetIndexAttrBitmap for something and
> realized that its header comment does not really explain things very
> well.  That was already the case before this commit, but it (this
> commit) did add new possible values without mentioning them.  I propose
> the attached comment-only patch.
> 

+1

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

  4. Re: pgsql: Ignore BRIN indexes when checking for HOT udpates

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2023-08-10T10:06:54Z

    On 2023-Aug-09, Tomas Vondra wrote:

> On 8/9/23 11:11, Alvaro Herrera wrote:
> > I was trying to use RelationGetIndexAttrBitmap for something and
> > realized that its header comment does not really explain things very
> > well.  That was already the case before this commit, but it (this
> > commit) did add new possible values without mentioning them.  I propose
> > the attached comment-only patch.
> 
> +1

Thanks for looking!  Pushed now.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/