Re: [PATCH] Don't block HOT update by BRIN index - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [PATCH] Don't block HOT update by BRIN index
Date
Msg-id 202107122037.2ymjotl4v3ot@alvherre.pgsql
Whole thread Raw
In response to Re: [PATCH] Don't block HOT update by BRIN index  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: [PATCH] Don't block HOT update by BRIN index  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-hackers
On 2021-Jul-12, Tomas Vondra wrote:

> 2) Do we actually need to calculate and store hotblockingattrs
> separately in RelationGetIndexAttrBitmap? It seems to me it's either
> NULL (with amhotblocking=false) or equal to indexattrs. So why not to
> just get rid of hotblockingattr and rd_hotblockingattr, and do something
> like
> 
>   case INDEX_ATTR_BITMAP_HOT_BLOCKING:
>     return (amhotblocking) ? bms_copy(rel->rd_hotblockingattr) : NULL;
> 
> I haven't tried, so maybe I'm missing something?

... What?  I thought the whole point is that BRIN indexes do not cause
the columns to become part of this set, while all other index types do.
If you make them both the same, then there's no point.

-- 
Álvaro Herrera              Valdivia, Chile  —  https://www.EnterpriseDB.com/
"La libertad es como el dinero; el que no la sabe emplear la pierde" (Alvarez)



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Fix comments of heap_prune_chain()
Next
From: Thomas Munro
Date:
Subject: Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.