Re: text_position worst case runtime - Mailing list pgsql-hackers

From Greg Stark
Subject Re: text_position worst case runtime
Date
Msg-id 87k68hopr7.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: text_position worst case runtime  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: text_position worst case runtime  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Alvaro Herrera <alvherre@commandprompt.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



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: [pgsql-advocacy] Toward A Positive Marketing Approach.
Next
From: Tom Lane
Date:
Subject: Re: text_position worst case runtime