Re: [PATCH] Don't block HOT update by BRIN index

Alvaro Herrera <alvherre@alvh.no-ip.org>

From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Josef Šimánek <josef.simanek@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2021-07-12T20:37:40Z
Lists: 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)



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Ignore BRIN indexes when checking for HOT updates

  2. Move test for BRIN HOT behavior to stats.sql

  3. Ignore BRIN indexes when checking for HOT udpates