| From: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
|---|---|
| To: | James Addison <jay(at)jp-hosting(dot)net> |
| Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Question: consolidating strpos searches? |
| Date: | 2025-01-04 19:03:59 |
| Message-ID: | CAKAnmm+YvxoQgFrQNTUm1gNh3NSHqbwie4fx--dLp7xXjdj=9Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Sat, Jan 4, 2025 at 12:16 PM James Addison <jay(at)jp-hosting(dot)net> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | jian he | 2025-01-05 04:52:15 | Re: Re: proposal: schema variables |
| Previous Message | Tom Lane | 2025-01-04 17:45:11 | Re: Question: consolidating strpos searches? |