From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | James Addison <jay(at)jp-hosting(dot)net> |
Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: Question: consolidating strpos searches? |
Date: | 2025-01-04 17:45:11 |
Message-ID: | 634658.1736012711@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
James Addison <jay(at)jp-hosting(dot)net> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Sabino Mullane | 2025-01-04 19:03:59 | Re: Question: consolidating strpos searches? |
Previous Message | James Addison | 2025-01-04 17:16:06 | Question: consolidating strpos searches? |