Euler Taveira

All pg_similarity functions return `double precision`. `double precision` is inexact [1]. Use a cast like: ``` select cast(cosine('Michael C', 'Michael C') as numeric(3,2)) < 1.0; ```

@df7cb v12beta1 is on my radar. You were faster than me. I will provide a fix ASAP.

@df7cb could you check again? I tested pg_similarity down to 9.2.

@df7cb I'm waiting your confirmation. Thanks. ;-)

pg_similarity supports GIN indexes. Indexes are **not** supported by all functions (check OPERATOR CLASS in `pg_similarity--1.0.sql` for the supported operators). pg_similarity is for `text` data types. However, cast to `text`...

Your assumption is correct. Example: ``` euler=# create table dictptbr (p text); CREATE TABLE euler=# copy dictptbr (p) from '/usr/share/dict/brazilian'; COPY 275502 euler=# create index on dictptbr using gin(p gin_similarity_ops);...

Your WHERE clause has low selectivity (1039192 of 1603423 rows), hence, `Bitmap Heap Scan` has to read and discard more than 1 million rows (actual time=3516.233..12101.172). If you add BUFFERS...

No. But if your database is big (several terabytes), you should consider using `pglogical_create_subscriber` that creates a logical instance from a base backup. It is faster than a logical clone....

Please provide a test case.

It seems similar to issue #336 but I didn't observe a crash. Could you try building from this repository to figure out it is the same issue that was fixed...