Как стать автором
Обновить
69
0
Oleg Bartunov @zen

Пользователь

Немного о деревьях

Можете мне скинуть dump базы, я сейчас тестирую новые индексы для ltree, хочу производительность померять.

Опыт тестирования PostgreSQL 13 на ARM-серверах HUAWEI TaiShan 200

Как верхний и нижний графики соотносятся друг с другом ? Желтый цвет вы специально выбрали, чтобы мы глаза ломали ?

Just for fun: команда PVS-Studio придумала мониторить качество некоторых открытых проектов

Отлично, надеюсь вы не будете генерить большое количество ложных срабатываний, а так будет интересно следить за постгресом, где будут результаты >

Архитектура и программирование микрокалькулятора HP-41

Через мажоров, коих хватало в универе, покупал, как и батарейки.

Архитектура и программирование микрокалькулятора HP-41

У меня был HP-41CV, инфракрасный принтер, считал на нем свой диплом в 1981 году. До сих пор помню, как извращался, чтобы в память уместиться, любил его нежной любовью, у нас на физфаке было несколько любителей этих калькуляторов, помню даже журналы их америки гуляли со всякими фишками, типа вход в инженерное меню.

SQL HowTo: префиксный FTS-поиск с релевантностью по дате

Мы сами не поддерживаем, но сообщество собирает
apt.postgresql.org/pub/repos/apt/pool/main/p/postgresql-rum
Я думаю про то, чтобы RUM сделать GIN-ом в сообществе.

История слона Slonik, логотипа PostgreSQL

Я когда-то писал про логотип постгреса obartunov.livejournal.com/186860.html
Если в кратце, то предложил его David Yang 3 апреля 1997 года, а сделали наши ребята из Питера.

Bonsai: фамильный вики-движок

Мне кажется, что с полнотекстовым поиском вы поторопились. Надо поставить русскую морфологию, например, отсюда github.com/postgrespro/hunspell_dicts и все должно работать. Дело в том, что по-умолчанию используется стеммер snowball, который довольно тупой.
Вот, что получается:

select ts_lexize('russian_stem','Иванова'), ts_lexize('russian_stem','Иванов'), ts_lexize('russian_stem','Иван');
ts_lexize | ts_lexize | ts_lexize
-----------+-----------+-----------
{иванов} | {иван} | {ива}
(1 row)

Понятно, что ничего хорошего не получится. Если поставить hunspell_ru_ru, то ситуация лучше
select ts_lexize('russian_hunspell','Иванова'), ts_lexize('russian_hunspell','Иванов'), ts_lexize('russian_hunspell','Иван');
ts_lexize | ts_lexize | ts_lexize
-----------+-----------+-----------
(null) | {иван} | {иван}
(1 row)

russian_aot_hunspell выдает побогаче
select ts_lexize('russian_aot_hunspell','Иванова'), ts_lexize('russian_aot_hunspell','Иванов'), ts_lexize('russian_aot_hunspell','Иван');
ts_lexize | ts_lexize | ts_lexize
----------------------------------+-----------+-----------
{иванов,иваново,ивановец,иванов} | {иванов} | {иван}
(1 row)

Можно в конце-концов сделать словарь синонимов и вбить туда исключения, я рекомендую использовать dict_xsyn для гибкости.

Короче говоря, можно все настроить с постгресом. У меня в ЖЖ есть несколько постов на тему FTS . Прошлой осенью я делал доклад в Лиссабоне на PGConf.eu, там тоже можно посмотреть на предмет словарей. Если что непонятно, обращайтесь. Меньше зависимостей, проще система.

Постгресовая стата без нервов и напрягов

Алексей, а трудно графику добавить? Я gnuplot использую, чтобы глядеть вживую на изменение параметров. Организуй трубу в гнуплот и он в соседнем окне будет показывать бегущий график.

Новый релиз PostgreSQL 9.6: вклад Postgres Professional

Вот здесь можно посмотреть http://www.sai.msu.su/~megera/postgres/talks/pgopen-2016-rum.pdf и ранняя версия доклада http://www.sai.msu.su/~megera/postgres/talks/pgcon-2016-fts.pdf

Когда использовать неструктурированные типы данных в PostgreSQL? Сравнение Hstore vs. JSON vs. JSONB

Два года назад рассказывал в Токио про hstore и jsonb, может кому пригодится — http://www.sai.msu.su/~megera/postgres/talks/semi-structured-postgresql-japan.pdf

PostgreSQL на многоядерных серверах Power 8

Freund должно читаться как «Фройнд»
Точно, друг означает.
но, как бы, в 2015 (2015, Карл!) году когда даже в десктопах торчат по 6-8 ядер, обрабатывать клиентский запрос ОДНИМ потоком…

Уже сейчас можно писать расширения, которые могут пользовать несколько ядер. Hans-Jürgen Schönig скоро выпустит такое расширение (не трогая ядра базы!) для агрегатов, вот его пример:
agg=# SET agg.hash_workers = 1;
SET
Time: 0.269 ms
agg=# SELECT val1, 
avg(id),
sum(id),
min(id),
max(id)
FROM t_agg 
GROUP BY 1 
LIMIT 2;
val1 | avg | sum | min | max 
------+----------------------+----------------+-----+---------
34 | 2500014.000000000000 | 12500070000000 | 34 | 4999994
25 | 2500005.000000000000 | 12500025000000 | 25 | 4999985
(2 rows)
Time: 62983.545 ms
agg=# SET agg.hash_workers = 10;
SET
Time: 0.161 ms
agg=# SELECT val1, 
avg(id),
sum(id),
min(id),
max(id)
FROM t_agg 
GROUP BY 1 
LIMIT 2;
val1 | avg | sum | min | max 
------+----------------------+----------------+-----+---------
34 | 2500014.000000000000 | 12500070000000 | 34 | 4999994
25 | 2500005.000000000000 | 12500025000000 | 25 | 4999985
(2 rows)
Time: 8265.947 ms
Таким образом, многое в ваших руках уже сейчас. Но это конечно только часть того, что планируется.

Отсутствие партицирования — тоже огромный недостаток.
Да, схему секционирования надо менять, мы этим тоже занялись и даже есть рабочее название проекта «pg_pathman», которые поможет нам генерить только нужные path-ы и передавать их планеры и избежать гигантского оверхеда перебора кучи ненужных планов. Это тоже часть работ по секционированию, но приятно, что она вполне обозримая и уже даст возможность работать с большим количеством разбиений. Возможно, надо будет объединиться с pg_partman.
Передайте Андресу
Передал, более того, Андрес приедет зимой на pgconf.ru с докладом по масштабируемости постгреса, так что вы сможете с ним поговорить лично.

Алгоритм извлечения информации в ABBYY Compreno. Часть 1

Древесные связи убили, может лучше написать древовидные?

Памятка евангелиста PostgreSQL: критикуем MySQL грамотно

У нас технический блог по постгресу, а нам предложили читать про мифы о MySQL. Текст написан складно, но вот только непонятны цели. Зачем-то оскорбили нашу компанию Postgres Professional, которая образовалась только в феврале и где она могла обидеть MySQL, мне непонятно. Автор не сознается, ну да ладно с ним. Я приведу несколько ссылок, чтобы люди смогли посмотреть технические детали двух субд.

1. Википедия — https://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
2. http://sql-workbench.net/dbms_comparison.html
3. https://www.wikivs.com/wiki/MySQL_vs_PostgreSQL?

Последняя ссылка особенно хороша и без каких-либо холиваров. В частности, там написано: «PostgreSQL was not available on Windows. First windows native version was 8.0. This was an advantage for MySQL.» Вот с этим я согласен.

Памятка евангелиста PostgreSQL: критикуем MySQL грамотно

Вы написали про нашу компанию нелестные слова, мне это неприятно, я хочу у вас узнать, почему вы допускаете такие слова в публичном блоге PostgreSQL. Я завтра спрошу ребят, кто вам так не угодил, раз вы не признаетесь.

Памятка евангелиста PostgreSQL: критикуем MySQL грамотно

Вы меня не поняли, кого вы посчитали сотрудниками Postgres Professional? Ни одного сотрудника в обсуждении я не увидел. Если вы считаете Мишу Тюрина нашим сотрудником, так это не так, увы. Миша является VIP в Avito.ru, главный за все базы. Поэтому, поправьтесь еще раз и окончательно.

Я не обижаюсь, а наоборот, хочу вас немного поправить, чтобы больше таких конфузов не было. Неужели вы не видите, что я до сих пор никого не заминусовал :) У вас есть слог и рвение, что не очень часто совпадает в нашем техническом мире, поэтому я вас призываю к созиданию, а не к обидкам и нападкам. Можете представить, сколько всего я наблюдал за 20 лет опенсорса :)

Памятка евангелиста PostgreSQL: критикуем MySQL грамотно

Читал-читал и все жду, когда вы исправите «полуграмотные утверждения» на что-то более нейтральное.

Что касается конференций, то я еще раз утверждаю, что у вас просто эффект преломления сознания. Дискусии бывают жаркие, но специально никто ни на кого не наезжают, только технические споры. Вот пример, кстати, с моим участием, совместной встречи двух сообществ, найдите там наезды :)
postgresmen.ru/articles/postgresql-vs-mysql-moscow-2009

Памятка евангелиста PostgreSQL: критикуем MySQL грамотно

Ну вот, вы все-таки холивар развиваете. Вы про фичи напишите, мы же тут разработчики и инженеры. Вы же просто не представляете, как делается выбор в больших проектах, а мы говорим про нашу реальную головную боль. Под религиозными взглядами я имел ввиду то, какой опыт уже имел конкретный человек и с чем знакома его команда. Если все имели опыт работы с mysql, то скорее всего и надо выбирать ее. Если вы хотите помочь человеку с нуля, причем этому человеку совсем по барабану мифы и наследия прошлых времен, то ему нужна совсем другая статья. Холиварщиков хватает и без вас, давайте позитив делать, а это означает употребите ваши умения на благо.

Памятка евангелиста PostgreSQL: критикуем MySQL грамотно

Вот вы везде говорите про 5.7. Это про оракловый mysql имеете ввиду и серьезно думаете, что кто-то будет сейчас оракловой проприетарщиной пользоваться? А что в mariadb с этим? В какой версии есть нативный json, fts и таблицы не в myisam?

Информация

В рейтинге
Не участвует
Откуда
Москва и Московская обл., Россия
Работает в
Зарегистрирован
Активность