Fujii Masao
masao****@gmail*****
2013年 7月 24日 (水) 04:28:20 JST
On Tue, Jul 23, 2013 at 11:45 PM, Beena Emerson <memis****@gmail*****> wrote: > On Mon, Jul 22, 2013 at 10:44 PM, Fujii Masao <masao****@gmail*****> wrote: >> >> On Tue, Jul 23, 2013 at 12:20 AM, Amit Langote <amitl****@gmail*****> >> wrote: >> > On Mon, Jul 22, 2013 at 10:57 PM, Beena Emerson >> > <memis****@gmail*****> wrote: >> >> Hello, >> >> >> >> Modules pg_trgm and pg_bigm cannot be installed in the same database >> >> because >> >> both declare the operator "gin_trgm_ops". >> >> >> >> Module pg_bigm defines two operator classes: >> >> 1. gin_bigm_ops >> >> 2. gin_trgm_ops >> >> >> >> The definition of both the operators is exactly same and the second >> >> "gin_trgm_ops" is defined for backward compatibility (stated in >> >> comments). >> >> There is no apparent need to declare gin_trgm_ops. By deleting this >> >> operator, we can install pg_bigm and pg_trgm in the same database. >> >> >> >> The attached patch deletes the pg_trgm_ops and also, makes necessary >> >> changes >> >> to upgrade to version 1.1. >> >> >> > >> > Thanks for this update. In fact, having these two co-exist might help >> > in scenarios where it would be desirable to have both a pg_trgm index >> > and a pg_bigm index on the same set of columns of a relation. In such >> > a case, I have observed in past experiments that the planner chooses >> > bigm index for searches involving 1-2 character strings. and trgm >> > index for >=3 character string searches. That is desirable for >> > performance reasons. >> > >> > What do others think? >> >> I agree that this is good improvement. >> >> Beena, >> Don't we need pg_bigm--1.0--1.1.sql? > > > I am sorry I missed this. > pg_bigm--1.0--1.1.sql file would be required to upgrade from 1.0 to 1.1. > > I have attached an v2 patch. > It just drops the OPERATOR CLASS gin_trgm_ops in pg_bigm--1.0--1.1.sql. Thanks for updating the patch! Committed. > Kindly note that if an existing index uses "gin_trgm_ops" then it will not > possible to upgrade from 1.0 to 1.1. If this is to be allowed then the DROP > ... CASCADE can be used in pg_bigm--1.0--1.1.sql. However, I feel this > approach will not be appropriate as it would delete all indexes using the > operator gin_trgm_op. Sounds reasonable. > A note regarding this is probably needed to be added to the documentation. Maybe when we release the version 1.1, we should write the release note and include this memo about the compatibility in the release note. Regards, -- Fujii Masao
Fork