Re: text_position worst case runtime

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: text_position worst case runtime
Дата
Msg-id 87k68hopr7.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: text_position worst case runtime  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: text_position worst case runtime
Список 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 по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: [pgsql-advocacy] Toward A Positive Marketing Approach.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: text_position worst case runtime