public inbox for [email protected]help / color / mirror / Atom feed
Question: consolidating strpos searches? 4+ messages / 3 participants [nested] [flat]
* Question: consolidating strpos searches? @ 2025-01-04 17:16 James Addison <[email protected]> 0 siblings, 2 replies; 4+ messages in thread From: James Addison @ 2025-01-04 17:16 UTC (permalink / raw) To: [email protected] --000000000000e24cbc062ae48da6 Content-Type: text/plain; charset="UTF-8" Hello and Happy New Year, I'd like to validate or reject a performance-related PostgreSQL patch idea, regarding multiple strpos calls that operate on a common text input. ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Question: consolidating strpos searches? @ 2025-01-04 17:45 Tom Lane <[email protected]> parent: James Addison <[email protected]> 1 sibling, 0 replies; 4+ messages in thread From: Tom Lane @ 2025-01-04 17:45 UTC (permalink / raw) To: James Addison <[email protected]>; +Cc: [email protected] James Addison <[email protected]> writes: > In other words: each additional strpos(value, ...) expression > increased the evaluation time by a similar, significant duration of > two seconds. This seems to confirm the basis that each expression is > currently evaluated separately, by an independent read from the input > text. That's correct. We have not felt a need to try to identify duplicate function calls: the cost of looking for them would seldom be repaid, so that such an optimization would be a net loss for most people. (In your example, they're not even truly duplicates.) > I'd like to suggest the introduction of a documented multiple string > matching algorithm[1], to yield results for each of multiple strpos > calls while only reading through their common input text at-most once. This seems like something with a pretty narrow audience. I'd suggest building it as an extension rather than trying to persuade people it belongs in core Postgres. regards, tom lane ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Question: consolidating strpos searches? @ 2025-01-04 19:03 Greg Sabino Mullane <[email protected]> parent: James Addison <[email protected]> 1 sibling, 1 reply; 4+ messages in thread From: Greg Sabino Mullane @ 2025-01-04 19:03 UTC (permalink / raw) To: James Addison <[email protected]>; +Cc: [email protected]; Tom Lane <[email protected]> On Sat, Jan 4, 2025 at 12:16 PM James Addison <[email protected]> wrote: > In the context of considering writing a patch: would the complexity of > implementing such a feature for PostgreSQL be worth the potential > performance benefits? Probably not. As Tom said, this sounds like it should be tried as an extension. 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. There are other ways to solve this particular issue. Among them would be using OR not AND in your contrived example, using partial indexes, using pg_trgm, using regular expressions ( i.e. WHERE value ~ '(known|suffix)' ), redesigning your table and/or queries, and outsourcing the searching of large strings to a system more suitable for it. Cheers, Greg ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Question: consolidating strpos searches? @ 2025-01-15 23:58 James Addison <[email protected]> parent: Greg Sabino Mullane <[email protected]> 0 siblings, 0 replies; 4+ messages in thread From: James Addison @ 2025-01-15 23:58 UTC (permalink / raw) To: Greg Sabino Mullane <[email protected]>; +Cc: [email protected]; Tom Lane <[email protected]> On Sat, 4 Jan 2025 at 19:04, Greg Sabino Mullane <[email protected]> wrote: > > On Sat, Jan 4, 2025 at 12:16 PM James Addison <[email protected]> wrote: >> >> In the context of considering writing a patch: would the complexity of implementing such a feature for PostgreSQL be worth the 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. There are other ways to solve this particular issue. Among them would be using OR not AND in your contrived example, using partial indexes, using pg_trgm, using regular expressions ( i.e. WHERE value ~ '(known|suffix)' ), redesigning your table 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. ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2025-01-15 23:58 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-01-04 17:16 Question: consolidating strpos searches? James Addison <[email protected]> 2025-01-04 17:45 ` Tom Lane <[email protected]> 2025-01-04 19:03 ` Greg Sabino Mullane <[email protected]> 2025-01-15 23:58 ` James Addison <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox