From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Zhihong Yu <zyu(at)yugabyte(dot)com> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: index for inet column |
Date: | 2022-07-07 22:42:37 |
Message-ID: | 3126109.1657233757@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Zhihong Yu <zyu(at)yugabyte(dot)com> writes:
> I was able to create gin index on inet column in PG.
> GIN is good with points/elements in sets. Is gin a good index for inet
> column ?
As far as Postgres is concerned, inet is a scalar type: it has a
linear sort order, and there aren't many operations on it that are
concerned with identifiable sub-objects. That means btree is a
perfectly fine index type for it, while GIN (which lives and dies by
sub-objects) is pretty off-point. I suppose you used btree_gin for
your index, because there are no other GIN opclasses that would take
inet. As the name implies, that's a poor man's substitute for btree;
there is nothing it does that btree doesn't do better.
Generally speaking, the use-case for btree_gin is where you want to
make a single, multi-column index in which one column is a collection
type (that is well-suited for GIN) but another is just a scalar type.
If you're making a one-column index with btree_gin, you're doing it
wrong.
> It seems gist index would be better.
Largely the same comments apply to GiST: it's not really meant for
scalar types either.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2022-07-07 23:21:13 | Re: System catalog documentation chapter |
Previous Message | Michael Paquier | 2022-07-07 22:38:49 | Re: BUG #17448: In Windows 10, version 1703 and later, huge_pages doesn't work. |