i am trying to create gin index on bigint column and getting an error (PostgreSQL 9.1.9 / Debian 7).
CREATE TABLE test (id bigint CONSTRAINT test_pkey PRIMARY KEY, field bigint);
CREATE INDEX idx_test_field ON test using GIN(field);
ERROR: data type bigint has no default operator class for access method "gin"
HINT: You must specify an operator class for the index or define a default operator class for the data type.
Is there no default support for int8 gin,gist indexes ?
There's generally no reason to create a GiST or GIN index on a primitive type.
If you do require this - say, if you want a composite index that includes both some primitive types and some more complex GiST / GIN-only index types - then you will want the btree_gist or btree_gin modules, as appropriate.
CREATE EXTENSION btree_gin;
Related
I'm getting error while I use Exclude constraint using gist
ALTER TABLE tbl_product ADD EXCLUDE USING gist (base_id WITH =, lifetime WITH &&);
ERROR: data type uuid has no default operator class for access method "gist"
HINT: You must specify an operator class for the index or define a default operator class for the data type.
Note:
base_id datatype is uuid,
lifetime datatype is period
I am using PostgreSQL 9.4. I have to use 9.4 only as I don't have any other option since I am unable to install temporal extension in 9.5, 9.6 and 10 are gives an error.
You'll need the btree_gist extension for that:
btree_gist provides GiST index operator classes that implement B-tree equivalent behavior for the data types int2, int4, int8, float4, float8, numeric, timestamp with time zone, timestamp without time zone, time with time zone, time without time zone, date, interval, oid, money, char, varchar, text, bytea, bit, varbit, macaddr, macaddr8, inet, cidr, uuid, and all enum types.
Unfortunately support for uuid was only added in v10.
With v10, you should be able to use
base_id gist_uuid_ops WITH =
in your exclusion constraint.
With 9.4, you could cast the column to a different type first:
(base_id::text) gist_text_ops WITH =
The accepted answer is correct, btree_gist is needed, however the suggested solution does not work (at least not in v12 in 2021). If you've been getting errors like in original question you should do the following:
CREATE EXTENSION IF NOT EXISTS btree_gist;
ALTER TABLE tbl_product ADD EXCLUDE USING gist (base_id WITH =, lifetime WITH &&);
As a bonus, I've been using it in Elixir & Ecto 3.5 and here's how to do this in Ecto migration:
execute "CREATE EXTENSION IF NOT EXISTS btree_gist"
create constraint(:tbl_product, "constraint_name", exclude: ~s|gist ("base_id" WITH =, lifetime WITH &&)|)
For example
CREATE INDEX my_index_name
ON public.my_table USING btree
(my_column int8_ops)
TABLESPACE pg_default;
vs
CREATE INDEX my_index_name
ON public.my_table USING btree
(my_column)
TABLESPACE pg_default;
What is the difference?
As much as I dislike quoting verbatim, I think what is written in the manual describes it most correctly and succintly, and I doubt I could do better:
The operator class identifies the operators to be used by the index
for that column. For example, a B-tree index on the type int4 would
use the int4_ops class; this operator class includes comparison
functions for values of type int4. In practice the default operator
class for the column's data type is usually sufficient. The main
reason for having operator classes is that for some data types, there
could be more than one meaningful index behavior. For example, we
might want to sort a complex-number data type either by absolute value
or by real part. We could do this by defining two operator classes for
the data type and then selecting the proper class when making an
index. The operator class determines the basic sort ordering (which
can then be modified by adding sort options COLLATE, ASC/DESC and/or
NULLS FIRST/NULLS LAST).
As for your example, if my_column is defined as type int8, then specifying the operator class as int8_ops is moot, as that would be the default operator for that type.
I've created a table to investigate text searching and using GIST and GIN indexes:
CREATE TABLE test
(
id serial NOT NULL,
the_text text,
CONSTRAINT test_pkey PRIMARY KEY (id)
)
And added some random values:
insert into test values (generate_series(1,100000), md5(random()::text))
And wanted to create GIN index:
create index on test using gin(the_text);
But I had an error:
ERROR: data type text has no default operator class for access method "gist"
Could you help me with that?
You need to enable :btree_gin or :btree_gist as well, since it's some sort of dependency for CREATE INDEX to work. The following worked for me and fixed the message ERROR: data type text has no default operator class for access method "gin"
CREATE EXTENSION pg_trgm;
CREATE EXTENSION btree_gin;
CREATE INDEX index_email_gin ON users USING GIN (email);
For full text search use:
CREATE INDEX test_gin_idx ON test USING gin (to_tsvector('english', the_text));
For trigram search you can use pg_trgm extension
CREATE EXTENSION pg_trgm;
CREATE INDEX test_the_text_gin_idx ON test USING GIN (the_text gin_trgm_ops);
I need to have something equivalent to this exclusion constraint
drop table if exists t;
create table t (
i int,
tsr tstzrange,
exclude using gist (i with =, tsr with &&)
);
ERROR: data type integer has no default operator class for access method "gist"
HINT: You must specify an operator class for the index or define a default operator class for the data type.
I guess the problem is obvious from the error message. How to do it?
You need to install the additional module btree_gist to make it work. The module installs the missing operator class.
Details in this related answer:
Exclusion constraint on a bitstring column with bitwise AND operator
More at this answer on dba.SE:
PostgreSQL EXCLUDE USING error: Data type integer has no default operator class
How can I create a case insensitive index or constraint in HSQL running in PostgreSQL (;sql.syntax_pgs=true) mode?
In Postgres, it can be done with lower() or lcase():
CREATE UNIQUE INDEX lower_username_index ON enduser_table ((lcase(name)));
PostgreSQL also has the CITEXT datatype, but unfortunately it does not seem to be supported in HSQL.
I'm currently at HSQL 2.2.8 and PostgreSQL 9.0.5. Alternatively, other in-memory databases that might be a better fit for testing PostgreSQL DDL and SQL?
Thanks in advance!
With HSQLDB, it's better to define a UNIQUE constraint, rather than a unique index.
There are two ways of achieving your aim:
Change the type of the column to VARCHAR_IGNORECASE, then use ALTER TABLE enduser_table ADD CONSTRAINT CONST_1 UNIQUE(name)
Alternatively, create a generated column then create the UNIQUE constraint on this column. `ALTER TABLE enduser_table ADD COLUMN lc_name VARCHAR(1000) GENERATED ALWAYS AS (LCASE(name))'
With both methods, duplicate values in the NAME column are rejected. With the first method, the index is used for searches on the NAME column. With the second method, the index is used for searches on the lc_name column.
(UPDATE) If you want to use the PosgreSQL CITEXT type, define the type in HSQLDB, then use the first alternative.
CREATE TYPE CITEXT AS VARCHAR_IGNORECASE(2000)
CREATE TABLE enduser_table (name CITEXT, ...
ALTER TABLE enduser_table ADD CONSTRAINT CONST_1 UNIQUE(name)