Re: Question: consolidating strpos searches?
От | James Addison |
---|---|
Тема | Re: Question: consolidating strpos searches? |
Дата | |
Msg-id | CALDQ5NzmGnrnCWFSu=w-myYbfRH0K-3JrY0PunMSm3+16-JJ8w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Question: consolidating strpos searches? (Greg Sabino Mullane <htamfids@gmail.com>) |
Список | pgsql-performance |
On Sat, 4 Jan 2025 at 19:04, Greg Sabino Mullane <htamfids@gmail.com> wrote: > > On Sat, Jan 4, 2025 at 12:16 PM James Addison <jay@jp-hosting.net> wrote: >> >> In the context of considering writing a patch: would the complexity of implementing such a feature for PostgreSQL be worththe potential >> performance benefits? > > Probably not. As Tom said, this sounds like it should be tried as an extension. Will do; thanks, both of you. >> And either way, is there more I should learn about and consider? How would I provide convincing supporting >> evidence if I do write a patch? > > As this is the performance mailing list, it might help to describe the real-world problem being encountered here. Thereare other ways to solve this particular issue. Among them would be using OR not AND in your contrived example, usingpartial indexes, using pg_trgm, using regular expressions ( i.e. WHERE value ~ '(known|suffix)' ), redesigning yourtable and/or queries, and outsourcing the searching of large strings to a system more suitable for it. The example is indeed contrived, and the idea doesn't resolve a problem I've encountered -- in fact, my interest stems from an open TODO item to implement Boyer-Moore string search. I began considering how to implement multiple string pattern search in that context -- but LIKE/ILIKE introduce a few non-trivial considerations -- notably wildcard patterns -- compared to strpos. Whether to require strict ordering of search results can also be relevant, depending on the pattern match approach (and boolean operators, as noted) involved.
В списке pgsql-performance по дате отправления: