Как дети малыe, ну сколько можно

[m_a_m_o_n]

WHERE upper(name) = upper(#{name

Comments

[thinker8086]

Эм?

Что неправильно и как надо?

[magicprinc]

будет full table scan т.к. функция не использует индекс

как надо: это зависит.

Обычно у БД можно указать, что varchar не case sensitive, тогда upper банально не нужен.

Если индекса по столбцу нет (например строк мало), то и так сойдет.

Если регистр не имеет значения можно сохранять сразу в upper - тогда при поиске не придется применять функцию.

#{name} - это синтаксис переменных в mybatis

[m_a_m_o_n]

Cамый юмор в том что для ilike в postgres
я так ещё и не нашёл иднекса.
В своей доке они пишут что для ignore-case
поиска как раз и надо делать индекс по lower(name)
и postgres типа разберётся.

P.S. но индекса конечно не было.

[thinker8086]

>> для ilike в postgres я так ещё и не нашёл индекса.

А такое бывает, кроме вариантов типа фултекст мускульного?

[magicprinc]

Можно вопрос немного не по теме.

Нужна максимальная скорость работы "голого" sql (т.е. простые insert/update/delete/select без тригеров, хранимых).
Кто быстрее postgres или MySQL?

Таблицы в сотни миллионов записей, с выскокой скоростью добавления, обновления.

Это БД SMS центра, если интересно.

Все отработанные записи архивируются в архивные таблицы вида блабла_YYMM, уже есть мысли даже блабла_YYMMDD.

Используется партиционирование (пока порядка 100 партиций).
Переход на Oracle тем не менее экономически не целесообразен (маржа бизнеса невысокая).

Про MySQL только ленивый не кричит, что это говно
http://habrahabr.ru/blogs/mysql/130999/

НО! Говно, не говно, а хваленые RabbitMQ и HornetQ от такой нагрузки просто умирают.

Вот размышляем может postgres?...
Просто с ним никто не работал. Известно, что он весь из себя полон функционала, но вот как там со скоростью, партициями, надежностью под нагрузками...

[m_a_m_o_n]

Если mysql+MyISAM - вряд ли postgres будет быстрее на INSERT,
но _возможно_ он будет быстрее на update/delete, за счёт версионности.

Большой вопрос, какие у вас SELECT.
Если WHERE id=123 то может быть стоит посмотреть в сторону
mongodb --journal (журнал обязательно)
Мастер-Мастер из коробки, сам не пробовал но друг пользуется,
и нагрузка у него там хорошая.

[magicprinc]

Не не. Какой MyISAM - он умирает через 5 минут.
__InnoDB__ MySQL 5.5

Select по индексам. Т.е. NoSQL как-то не накладывается.
Кроме того по архивным таблицам разные выборки (юзеры смотрят так и сяк), кроме того заботают агрегирующие джобы (OLAP вручную). Не готовы мы как-то к NoSQL.

Репликация у MySQL крайне медленная - однопоточная и может сильно лагать, как с этим у postgres?

[m_a_m_o_n]

>Select по индексам. Т.е. NoSQL как-то не накладывается.
В монго есть точно такие же индексы, т.е. если нужно
выбрать все сообщения по пользователю - это возможно.

>Репликация у MySQL крайне медленная - однопоточная и может сильно лагать, >как с этим у postgres?
А зачем вам репликация (ну кроме как бекапа), может быть если
каждая база будет содержать только часть данных (шардинг)
вас это устроет. Опять же, это хоошо решается с монго.

[smagen]

Есть ещё один способ.

http://www.postgresql.org/docs/9.1/static/citext.html

[m_a_m_o_n]

А индексы по таким столбцам есть?

[smagen]

Да, есть.

[m_a_m_o_n]

Спасибо, буду иметь в виду.

[magicprinc]

Случайно нашел книгу по PSQL, вдруг не знаете - делюсь

Работа с Postgresql
настройка, масштабирование
на русском языке (pdf, html, epub)

http://postgresql.leopard.in.ua/

Также интересно будет узнать Ваше мнение о данной книге.

[m_a_m_o_n]

Нормальная книжка, но основную доку всё равно читать нужно.