From: | Emre Hasegeli <emre(at)hasegeli(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: btree_gist into core? |
Date: | 2023-12-14 11:35:17 |
Message-ID: | CAE2gYzw=g5Cfyuo_jkhMey8jDFTxDyV3CNRp6eS8EHXYBajQLA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Thoughts?
I think it'd be really nice to do this without btree_gist.
I imagine something like this:
CREATE INDEX ON tbl USING gist (
range_col,
int_col USING btree
)
I think this would make the index access methods interface more
useful. Index access method developers wouldn't need to provide
operator classes for all data types. We could extend ACCESS METHOD
definition to allow this:
CREATE ACCESS METHOD my_hash_index
TYPE INDEX
IMPLEMENTS hash
HANDLER my_hash_index_handler
I realise this is a difficult project.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey M. Borodin | 2023-12-14 11:56:50 | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock |
Previous Message | tender wang | 2023-12-14 11:32:06 | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock |