| From: | Japin Li <japinli(at)hotmail(dot)com> |
|---|---|
| To: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
| Cc: | Kirill Reshke <reshkekirill(at)gmail(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Add IS_INDEX macro to brin and gist index |
| Date: | 2026-01-16 02:25:29 |
| Message-ID: | MEAPR01MB303148F74180D65C18004A79B68DA@MEAPR01MB3031.ausprd01.prod.outlook.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 15 Jan 2026 at 20:57, Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
> After looking at this more closely, I wonder if this is really doing
> what we want. For BRIN and GiST, you can only pass an index to the
> brin_page_items and gist_page_items functions respectively, and that
> only as to let the function know what relation the page comes from. The
> actual read from the index comes from get_raw_page().
>
> So in the regression database, I created
> create index on regress_constr_partitioned using brin (a);
>
> and then tried this
>
> select * from brin_page_items(get_raw_page('regress_constr_partitioned_a_idx1', 1), 'regress_constr_partition1_a_idx'::regclass);
>
> this gives me the following existing error:
> ERROR: cannot get raw page from relation "regress_constr_partitioned_a_idx1"
> DETALLE: This operation is not supported for partitioned indexes.
>
> but if I instead do it the other way around,
>
> select * from brin_page_items(get_raw_page('regress_constr_partition1_a_idx', 1), 'regress_constr_partitioned_a_idx1'::regclass);
>
> the error is now
> ERROR: "regress_constr_partitioned_a_idx1" is not a BRIN index
>
> I wonder ... shouldn't these reports be more similar? Or, there's also
> the alternative view that we don't _need_ to throw an error here. If I
> remove the new check, I get this
>
> select * from brin_page_items(get_raw_page('regress_constr_partition1_a_idx', 2), 'regress_constr_partitioned_a_idx1'::regclass);
> itemoffset │ blknum │ attnum │ allnulls │ hasnulls │ placeholder │ empty │ value
> ────────────┼────────┼────────┼──────────┼──────────┼─────────────┼───────┼───────
> 1 │ 0 │ 1 │ t │ f │ f │ t │
> (1 fila)
>
> which seems ... perfectly okay? I mean, why are you worried about this?
>
Thanks for the test. After rethinking, I agree — that BRIN/GIST index-type
check is useless.
OTOH, why don't we just do it the same way as the btree index functions?
brin_page_items(relname text, blkno bigint);
> --
> Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
> "Computing is too important to be left to men." (Karen Spärck Jones)
--
Regards,
Japin Li
ChengDu WenWu Information Technology Co., Ltd.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hayato Kuroda (Fujitsu) | 2026-01-16 02:26:19 | RE: code contributions for 2025, WIP version |
| Previous Message | Chao Li | 2026-01-16 02:06:51 | Re: Refactor replication origin state reset helpers |