Тут не исправить уже ничего, Господь, жги! Войти !bnw Сегодня Клубы
Привет, TbI — HRWKA! 1236.0 пользователей не могут ошибаться!
?6917
прекрасное6429
говно5890
говнорашка5512
хуита4698
anime3060
linux2645
music2628
bnw2594
рашка2562
log2340
ололо2119
pic1815
дунч1746
сталирасты1490
украина1437
быдло1435
bnw_ppl1377
дыбр1238
гімно1158

Попросил постгрес отсортировать три строки. Результат: https://30.rkn.gov.ru/ http://s31740.tistory.com/ https://31.rkn.gov.ru/ Предлагаю вам догадаться, как это работает. Это весело.
#1PW15F (3) / @komar / 113 дней назад
Вообще концепция shared buffers мне как раньше казалась ебанутой, так и сейчас кажется. Эти кеши/буферы работают примерно так же, как и линупсячьи. А может ли существовать идея гениальнее, чем продублировать кеш в одной и той же оперативной памяти? Я спрашивал у дядей DBA'ев, нахуя они нужны — те что-то блеют про прирост в производительности в 20%, если засрать буферами всю память. Охуенно.
#NWP4UE (2) / @komar / 150 дней назад
Отвечаю самому себе на #793J1I: надо было ебануть bgwriter_lru_maxpages = 0 в постгресе.
#WPJDL8 (0) / @komar / 151 день назад
> The database was created using collation version 2.31, but the operating system provides version 2.36. С превеликим удовольствием узнал, что PostgreSQL из коробки поражен чумой XXI века юникодом. В случае выполнения определенных условий перед каждым обновлением libc надо останавливать к хуям базу, а после него — делать REINDEX, а иначе индексы начнут показывать погоду на марсе.
#6CQN8L (0) / @komar / 401 день назад
=> SELECT CASE NULL WHEN NULL THEN 'null' ELSE 'not null' END; not null
#TA8X32 (2) / @komar / 437 дней назад
# SELECT int8range(1, 2, '[]'); int8range ----------- [1,3) да ебаное ты говно
#C1NP4K (0) / @komar / 517 дней назад
SKIP LOCKED работает не совсем ожидаемо, если блокируются строки из нескольких таблиц. То есть если сделать SELECT ... FOR UPDATE OF table1, table2 SKIP LOCKED, то строку в table1 он заблокирует без ожидания, а вот на table2 — встанет. Или ебнетеся с дедлоком, если нужна строка в table2 уже заблокирована и тоже ждет.
#GUS8BV (2) / @komar / 644 дня назад
pg_stat_statements заебись.
#ES7JDU (9) / @komar / 932 дня назад
> То есть номера идут без серьезных пропусков и по нарастающей. > 5. После более внимательного изучения устройства баз данных (а мы исходим из того, что регистры Минздрава работают под управлением свободно распространяемой системы управления базами данных PostgreSQL, как указано в отчете о внедрении информационной системы) мы склонны считать, что номера из базы не удаляются и не присваиваются повторно другим людям. Редкое зрелище: тупорылый уебок, которому хочется разбить ебало, не понимает, как работают сиквенсы, и откуда в них дырки; при этом это не пидорас-айтишник, а пидорас-журналист.
#AME8DZ (5) / @komar / 1051 день назад
Че-то мне совсем разонравился постгрес. Планировщик — ебаное говно, которое расчитано на работу неоптимизированных запросов в неоптимизированной базе, которая хотя бы большими кусками помещается в оперативную память. Короче говоря — в распиздяйском окружении. А в условии ограниченных ресурсов все плохо. В итоге у меня на весь инстанс глобально стоит: enable_bitmapscan = off enable_hashjoin = off enable_mergejoin = off — просто чтобы избавиться от появляющихся зависших запросов, из-за которых пользователи отфутболиваются по таймауту. Простой пример: изобретаем мы электронную почту. Делаем таблицу messages (user_id, date, ...) Делаем индекс для нее по (user_id, date DESC) Каждому пользователю показываем 50 последних писем при помощи WHERE user_id = ... ORDER BY date DESC. Ничего фантастического, самое обычное поведение самого обычного приложения. Все работает очень быстро: делается index scan и nested loop 50 раз. Но только покудова мы одновременно не джоиним messages с какой-нибудь второстепенной хуетой. Тут планировщик начинает делать bitmap index scan, потом hash/merge join, а потом sort by date DESC. Беда в том, что писем у пользователя может быть 100 штук, а может быть 100 000 штук. Bitmap index scan в этом случае выбирает целый миллион, потом все это «быстро» и «эффективно» (как задумывалось планировщиком) джоинится, потом фильтруется лишнее (до 100 000 строк), потом сортируется, потом берутся верхние 50 писем. В результате пользователь со ста тысячами писем не может зайти в свой почтовый ящик вообще: он видит только nginx gateway timeout. И ситуации подобные этой возникают постоянно. Иногда запрос работает хорошо, но только меняется аргумент в условии — все идет пиздой. Например, планировщик, которого попросили письма двухнедельной давности, может решить, что теперь-то эффективнее делать bitmap index scan — и все по-новой. Обычная статистика не помогает, потому что, как я уже говорил, писем может быть и 100, и 100 000. Но в среднем — голубцы. CREATE STATISTICS еще не опробовал. Надеюсь, конечно, что поможет, но едва ли это очевидное решение. Хуй, блять, знает, какие исходники надо ковырять, чтобы сделать планировщик ПЕССИМЕСТИЧНЕЕ. Чтобы, блять, если в теории возможно, что план по выборке 50 обоссаных писем может закончится бедой — он не пользовался этим планом. Хинтов в постгресе нет. Есть возможность отключать отдельные виды тактик на время сессии, и, по-моему, даже во время транзакции. Вообще, все это хуйня, и через «еб твою мать!» с ней можно справиться. Но основной тренд очень расстраивает.
#0QMYCY (8) / @komar / 1227 дней назад
Давайте переименуем pg_xlog в pg_wal, чтобы дебичи перестали чистить диск от «каких-то логов», а у нормальных людей все скрипты сломались к хуям.
#ADV64M (24) / @komar / 1273 дня назад
как же хуево жить в мире где антиджоины тормозят
#4QVANU (0) / @komar / 1323 дня назад
https://europepmc.org/article/med/32477687#free-full-text что это блядь за вольтрон-хуесос такой
#V8NSR6 (2) / @komar / 1328 дней назад
til pg_restore -j вся жизнь коту под хвост
#BA1NSQ (2) / @komar / 1333 дня назад
На какие грабли можно напороться, раздавая timestampz вместо timestamp налево и направо?
#YDLUVC (0) / @komar / 1989 дней назад
Придумайте, почему я не хочу created_at timestamptz NOT NULL DEFAULT statement_timestamp() Я, конечно, хотел сделать now(), как и все. Но потом понял, в случае параллельных транзакций с блокировками одного ресурса у меня может случиться TIME PARADOX.
#8KJPJ1 (11) / @komar / 2028 дней назад
еб твою мать на хуй, на postgresql.org/docs редизайн закопуйте, это начало конца
#61IGXN (2+1) / @komar / 2072 дня назад
http://komar.in/ru/быстрое-агрегирование-в-postgresql найдите там ошибки за меня, лень читать
#8N12UN (14+1) / @komar / 2132 дня назад

TIL jsquery

#COQJES (0) / @kerrigan / 2135 дней назад
ipv6 ready BnW для ведрофона BnW на Реформале Викивач Котятки

Цоперайт © 2010-2016 @stiletto.