From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | Josef Šimánek <josef(dot)simanek(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Don't block HOT update by BRIN index |
Date: | 2021-07-12 20:37:40 |
Message-ID: | 202107122037.2ymjotl4v3ot@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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)
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2021-07-12 20:44:53 | Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX. |
Previous Message | Alvaro Herrera | 2021-07-12 20:31:47 | Re: Fix comments of heap_prune_chain() |