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 →
-
Ignore BRIN indexes when checking for HOT updates
- 19d8e2308bc5 16.0 landed
-
Move test for BRIN HOT behavior to stats.sql
- fe60b67250a3 15.0 landed
-
Ignore BRIN indexes when checking for HOT udpates
- 5753d4ee320b 15.0 landed