​https://twitter.com/ryanchenkie/status/1303781123546324994

Пикантности добавляет то, что чувак работает в GraphQL Dev Rel в prisma :)

Повезло кому-то с работой...

TLDR: как сджойнить 1 миллион таблиц

К слову, в настройках PostgreSQL есть параметр join_collapse_limit, который отвечает за оптимизацию джойнов. По умолчанию он равен 8. Так вот, если в запросе джойнится больше 8 элементов, оптимизатор говорит, что у него лапки и просто джойнит все по очереди. У нас на этот случай, конечно же, есть warning :)

https://twitter.com/postgresql_007/status/1304308970790813703

​Пятничный SQL-WTF #3
Понедельничный SQL-TIL #3

Продолжение первой и второй части сборника внезапных синтаксических конструкций и неочевидного поведения в SQL. Все эксперименты проводились в PostgreSQL.

Скорее всего вы никогда не столкнетесь с таким синтаксисом в реальной жизни. Но зато сможете блеснуть эрудицией перед своими коллегами :)

1 wtf из 5 - implicit and explicit record
Под прошлым выпуском часто голосовали "так никто не пишет", когда я рассказывал о тонкостях использования ROW. Очень даже пишут :) В частности сравнение ROW() позволяет прилично сократить количество писанины и одновременно уменьшить вероятность ошибки:

UPDATE t 
SET (a,b) = (1,2)
WHERE (a,b) = (0,0)

или даже так:

SELECT ROW(1,2) IN (SELECT a,b FROM t)

Есть два способа объявления ROW - явный, в виде

ROW()

и неявный в виде

()

Так вот, неявный способ не работает для одного параметра, конструктор просто игнорируется:

SELECT pg_typeof(ROW(1)), pg_typeof((1))
-- record, integer

И соответственно, сравнить их между собой не удастся.

Возможно, вам немного надоели рассказы про ROW, но они неразрывно связанны с композитными типами, которые могут встретиться в совершенно разных местах. Поэтому иметь общее представление о ROW будет полезно.


2 wtf из 5 - IS [NOT] DISTINCT FROM
Вы наверняка знаете, что результат сравнения с NULL дает NULL. Не true или false, а NULL:

SELECT * FROM t
WHERE a = NULL

Не вернет ни одной записи. Конечно же на этот случай у нас есть правило :)
Для проверки на NULL используется конструкция

IS [NOT] NULL

Если мы хотим сравнить 2 колонки, каждая из которых может принимать значение NULL и при этом нас устроит, что NULL = NULL, мы будем вынуждены сделать так:

SELECT * FROM t1, t2
WHERE 
    t1.a = t2.a OR t1.a IS NULL AND t2.a IS NULL
    AND
    t1.b = t2.b OR t1.b IS NULL AND t2.b IS NULL

Писать не удобно, читать еще хуже... Но есть выражение, которое может сократить запись:

SELECT * FROM t1, t2
WHERE (t1.a, t1.b) IS NOT DISTINCT FROM (t2.a, t2.b)

Само собой, оно работает и для сравнивания колонок и значений, а не только типов record.


3 и 4 wtf из 5 - точность формулировки функциональных индексов
В рейтинге частотности правил SQL анализатора holistic.dev на третьем месте оказалось архитектурное правило de-morgan-laws, и я приводил пример во что раскрывается выражение

NOT (a IS TRUE)

и почему оно не эквивалентно

a = false

При использовании функциональных индексов, база производит сравнение точного выражения с константой, записанной в индексе и не пытается ничего вычислять.
However, the index expressions are not recomputed during an indexed search, since they are already stored in the index.

Если помнить об этом, то можно сильно сэкономить время, нервы и деньги. Пример, иллюстрирующий ситуацию:
Особенности использования индексов в PostgreSQL

Заголовок не отражает суть проблемы, т.к. никакой специфики Postgresql тут нет - так работает везде.

VALUE IS NOT NULL

эквивалентно

(VALUE IS NULL) = false

только в голове разработчика, где под сто триллионов нейронных связей. Для системы управления базой данных это 2 совершенно разных выражения :)

Хотел подкрепить свои слова в демке совершенно убойного проекта Cosette, который выводит математическую эквивалентность двух SQL выражений, но он не понимает IS NULL :(

В holistic.dev мы еще не закончили работу над системой, которая будет понимать сможет ли запрос использовать один из существующих индексов. Но мы активно над этим работаем :) В одном из следующих выпусков я расскажу что происходит при парсинге выражений WHERE и ON. Это очень непросто :)


5 wtf из 5 - views with check option
Помните, в прошлом выпуске историю про updatable views?
Так вот, это еще не конец :)
Вьюхи можно создавать так, чтобы при вставке или изменении через них возникало исключение, если добавляемые данные не соответствуют условию фильтрации внутри самой вьюхи! Просто добавьте WITH CHECK OPTION после описания запроса при создании :)

я знаю, чем все будут заниматься ближайшие дни...


https://toonify.justinpinkney.com/

​Хороших разработчиков не так много, как может показаться.
А если не рассматривать 23-летних синьоров, то и вообще никого не найти. Все либо в менеджерах, либо настолько в своем познании преисполнились, что к ним на кривой козе не подъедешь.
А работать кому-то надо...

У меня есть старый друг Миха. Он писал какие-то вундервафли для коммутатора в сотовом операторе, в котором я грохнул базу абонентов (https://news.1rj.ru/str/nosingularity/437) 20 лет назад...

Может на шарпах, может на крестах, на голых сях, js и на всем подряд. В базах сечет не хуже меня (почти, гыгы).

При этом он адекватный человек. Но как человек, он слаб. Поэтому ему больше всего нравится писать на питоне :)

Короче, если вам понадобится на парттайм или проект крутой бэкенд с воооот с такой экспертизой, стучите мне в личку (@antonrevyako) и я вас сконнекчу.

блин :(

Для специалистов по SQL собеседование платное

​​В прошлый понедельник SQL-TIL не зашел, поэтому я решил сделать перерыв :) Кип ин тач.

Первые три выпуска:
https://news.1rj.ru/str/nosingularity/535
https://news.1rj.ru/str/nosingularity/541
https://news.1rj.ru/str/nosingularity/548

​Морской бой в постгре:

https://github.com/Firemoon777/sql-battleships

Так проходит совет директоров тесла (прямо сейчас)

#prog

Переписал по работе одну утилиту для анализа логов. Раньше для разбора строк использовались регулярные выражения, а я заменил на наколенный лексер. В результате утилита, которая почти 23 гигабайта перемалывает за чуть больше, чем за 5 минут, стала на тех же данных работать за чуть меньше, чем полторы минуты. Результат, разумеется, тот же самый.

​Чат, ай нид хелб!

Возможно, не все знают, но я занимаюсь разработкой статического анализатора для SQL - holistic.dev

И я решил написать ряд статей с разбором результатов анализа баз разных опенсорсных проектов.
Да, прям как PVS-Studio на хабре.

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

И кажется, GitLab идеальный кандидат. RoR, много у кого есть и часто используется локально.

Поэтому ИЩЕТСЯ ДОНОР С ON-PREMISE GITLAB’ом!
Внимание!
У меня не будет доступа к вашим данным.
У меня не будет доступа к вашему коду.
Я не буду знать переименовали ли вы master в main и используете ли вы gitflow.
У меня даже коннекта к базе GitLab'а не будет.

Мне будет доступен только список SQL-запросов, которые GitLab делает к PostgreSQL.
И то их вы пришлете мне сами.

Схема базы у GitLab лежит в репозитории в готовом виде, а запросы делаются из ORM.

Очень важно, чтобы GitLab активно использовали, т.к. хочется собрать как можно больше разных запросов.
Интеграция займет 10-15 минут времени вашего админа.

Мне сложно предложить что-то ценное взамен, т.к. сам сервис holistic.dev на данный момент предлагается бесплатно. Но вы пишите, мы что-нибудь придумаем :)

Лайк, шер, предложения в личку @antonrevyako

​Сегодня в нескольких каналах обнаружил постмортемы о предыдущих местах работы :) Один из них от моего старого комрада Олега про 1.5 года работы в AppFollow:

https://news.1rj.ru/str/ITmoonIT/235

Там PostgreSQL 13 зарелизили:

https://www.postgresql.org/about/press/presskit13/ru/


тут я выкладывал документ с подробностями
https://news.1rj.ru/str/nosingularity/483

​elsaland/elsa
Elsa is a minimal, fast and secure runtime for Javanoscript and Typenoscript written in Go.
Language: Go
Stars: 104 Issues: 4 Forks: 6
https://github.com/elsaland/elsa