Thank you for the feedback.
In our setup it has actually worked per the explains provided making the query
run in milliseconds instead of seconds.
We weren't sure if this should be something that could be added natively with
future Postgres deployments.
Thanks,Efrain J. Berdecia
On Thursday, January 13, 2022, 12:58:27 AM EST, Tom Lane
<t...@sss.pgh.pa.us> wrote:
"Efrain J. Berdecia" <ejberde...@yahoo.com> writes:
> After attempting to use gin and gist indexes for our queries that run against
> citext columns, our team has come up with the following to make our queries
> run from 2 mins to 25ms;CREATE EXTENSION pg_trgmCREATE EXTENSION btree_gin
> --may not be needed, checking
> CREATE OPERATOR CLASS gin_trgm_ops_ci_newFOR TYPE citext USING ginASOPERATOR
> 1 % (text, text),FUNCTION 1 btint4cmp (int4, int4),FUNCTION 2
> gin_extract_value_trgm (text, internal),FUNCTION 3 gin_extract_query_trgm
> (text, internal, int2, internal, internal, internal, internal),FUNCTION 4
> gin_trgm_consistent (internal,int2, text, int4, internal, internal, internal,
> internal),STORAGE int4;
> ALTER OPERATOR FAMILY gin_trgm_ops_ci_new USING gin ADDOPERATOR 3 ~~ (citext,
> citext),OPERATOR 4 ~~* (citext, citext);ALTER OPERATOR FAMILY
> gin_trgm_ops_ci_new USING gin ADDOPERATOR 7 %> (text, text),FUNCTION 6
> (text,text) gin_trgm_triconsistent (internal, int2, text, int4, internal,
> internal, internal);
> Our question is, does anyone see any flaw on this?
Umm ... does it actually work? I'd expect that you get case-sensitive
comparison behavior in such an index, because those support functions
are for plain text and they're not going to know that you'd like
case-insensitive behavior.
You generally can't make a new gin or gist opclass without actually
writing some C code, because the support functions embody all
the semantics of the operators.
regards, tom lane
