[sqlalchemy] Re: `func.similarity` performance

Robert, my understanding is that SQLAlchemy knows nothing about the Postgres's `similarity` function - sqlalchemy.func just magically generates the SQL output depending on which member you invoke. Try `func.magic_unicorns()`. So, there's not much to optimize here - it outputs what you give it.

Re: [sqlalchemy] `func.similarity` performance

On Thursday, March 31, 2016 at 6:46:10 PM UTC-4, Robert Smith wrote: > > Thank you. That's a good idea but in this case, I'm really wondering if > sqlalchemy should use that small change to improve performance quite a bit > in this type of queries. > I've been in your place. 1. It sounds like

Re: [sqlalchemy] scoped_session, sessions and thread safety

On 03/31/2016 10:38 AM, Mehdi GMIRA wrote: > > 1) One limitation that i find to the scoped_session is that you're > limited to exactly one session by thread. that's not true at all, make as many sessions as you want from the sessionmaker() inside of it (or just use

Re: [sqlalchemy] `func.similarity` performance

On 03/31/2016 06:40 PM, Robert Smith wrote: Mike Bayer: Thank you for your response. I wasn't really asking whether the optimization I described above (using `%` instead of `similarity`) is correct or not. Based on some resources (e.g. Super Fuzzy Searching on PostgreSQL

Re: [sqlalchemy] `func.similarity` performance

Jonathan Vanasco: Thank you. That's a good idea but in this case, I'm really wondering if sqlalchemy should use that small change to improve performance quite a bit in this type of queries. Otherwise, I think I would need to rely on raw SQL to perform a similarity operation and I'm not sure if

Re: [sqlalchemy] `func.similarity` performance

Mike Bayer: Thank you for your response. I wasn't really asking whether the optimization I described above (using `%` instead of `similarity`) is correct or not. Based on some resources (e.g. Super Fuzzy Searching on PostgreSQL

Re: [sqlalchemy] `func.similarity` performance

On Thursday, March 31, 2016 at 9:43:11 AM UTC-4, Mike Bayer wrote: > > this is more of a Postgresql optimization question so I dont have any > insight on that. > FWIW, I generally handle these types of "optimize postgres" queries using a function to apply the filter - like this: def

Re: [sqlalchemy] `func.similarity` performance

On 03/30/2016 09:50 PM, Robert Smith wrote: I'm using sqlalchemy 1.0.12 with postgreSQL 9.4.6 with the pg_trgm extension enabled. Basically, I'm performing a similarity-based query on a single column: In [26]: str(session.query(Model).order_by(desc(func.similarity(Model.description,

Re: [sqlalchemy] scoped_session, sessions and thread safety

On 03/31/2016 03:30 AM, Mehdi GMIRA wrote: Thanks for the reply ! Ok, so if i understood what you said, the advice to use only one session per thread is related to the fact that the session's internals are not thread safe. It has nothing to do with the backend database's concurrency

Re: [sqlalchemy] scoped_session, sessions and thread safety

Thanks for the reply ! Ok, so if i understood what you said, the advice to use only one session per thread is related to the fact that the session's internals are not thread safe. It has nothing to do with the backend database's concurrency constraint. Some more questions: 1) One limitation