Re: text_position worst case runtime

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Tom Lane wrote:
> >> You've obviously missed the point of my concern, which is code bloat.
>
> > So why not just replace our code with better algorithms? We could use
> > Shift-Or or Shift-And which AFAIK are even better than Boyer-Moore.
>
> And how much code would those take? The bottom line here is that we
> don't have a pile of complaints about the performance of text_position,
> so it's difficult to justify making it much more complicated than it
> is now.

Even Boyer-Moore, while conceptually tricky isn't actually all that much code.

It seems somewhat contrary to the Postgres design philosophy to assume that
all strings are small.

Other databases have two different string data types, one that has a small
length limit (often only 255 bytes or so) and another that has all kinds of
awkward restrictions on how it can be used. Postgres allows text to contain
gigabytes of data and lets you use all the normal string functions on it.

It seems like having those string functions assuming the strings are small
compromises that design choice.

--
greg