I never went that far into learning SQL, but I assume that 'LIKE' is a substring match. As I see it, the two ways to improve the speed of it are to prioritise the easier to detect, and most frequent conditions, and whenever there is a shortcut, use it. This might mean double or more as many lines of code to implement the shortcuts. The OR operator in Go can indeed be parallelised, but you would be limited by the number of CPU cores, so again, prioritisation of more important results means you could find them and respond on that item even as the rest are being tested.
On Tuesday, 26 February 2019 07:08:00 UTC+1, RZ wrote: > > Thanks Tamas, > > Query itself is slow if i include all url strings. it takes about 10 mins. > But when i hit one at a time, i see better response overall. Yes so was > planning on running them in parallel. > > We only have read permissions and hence i am not allowed to add new index, > but good idea, will try reaching out to Admin and see if they can add this. > > i have not tried that way of similar to, will try that as well. > > > On Tuesday, 26 February 2019 00:36:26 UTC+5:30, Tamás Gulácsi wrote: >> >> How fast is the query? You can make it parallel, but if it is sliw, the >> you have to target that first. >> >> How big is the set of one user's all urls? How fast is to get this? Maybe >> adding some indexes may help >> >> >> How fast is the query with one pattern only? Maybe combining them into a >> "similar to '%(abc|def|ghi)%'" would be faster? >> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
