На самом деле это касается не только pgsql. Я, например, часто статистику и аналитику тяну из кликхауса. И если на огромных таблицах не учитывать ключи и особенности работы самой СУБД, то можно получить запросы которые будут работать час. Конечно, в некоторых случаях их не избежать (типа bulk insert), но что касается того что отдается пользователю, то оно должно отдавать все же быстро и здесь разные критерии оценки. В этом смысле разделение на OLAP и OLTP дизайн для таблиц помогает.
Если запрос выполняется долго из-за того, что много данных - это проблема прежде всего индекса т.к. это означает, что в выборку по индексу попадает много данных, которые потом нужно еще группировать и фильтровать, а значит cardinality индекса очень низкий.
Если же вам нужно подключать много таблиц к запросу, то, вроде очевидно, что надо следить за планом запроса и использовать для JOIN поля с ключами и индексами. JOIN вообще самая медленная операция в РСУБД. Альтернативным путем иногда является переход на SELECT-driven модель, чтоб избежать JOIN'ов.
Но в любом случае получается, что задача сводится к анализу статистики запрсов и вытягиванию самых медленных. Затем их рефакторинг и получаем то, что надо.
Помню в году 2019, сижу на совещании на работе. Обсуждаем модернизацию одной из центральных площадок сети с техдиром. Рядом сидит мой стажер. Мне звонок по мобильнику. После смятого представления девушка наинает мне рассказывать про какую-то открытую вакансию. Я ее слушал порядка минуты а потом спросил откуда она. Она сказала "СберКлауд". Я тогда уточнил связано ли это как-то со Сбером, она ответила положительно. Тогда я ответил "А Сбербанк? Нет, спасибо. Меня такое не интересует, до свидания". Я видел как офигели коллеги от того что произошло и как они старались не смеяться. А я до сих пор не жалею о сделанном.
Но вот зачем в эту формулу добавлять ещё один поток с чтением, для меня загадка.
Да, я именно об этом.
Я когда-то очень давно (полагаю, что это было начало 2013 года), попал на JavaDay. Ну как...Начальник сказал записаться и пойти в порядке саморазвития. В общем, докладчик был из Одноклассников и рассказывал как они стартовали, как развивался код. Но поворотной точкой стал их выбор в сторону использованися Unsafe. Получается , рано или поздно все равно надо будет писать что-то что выходит за грани отведенной песочницы?
N.B. Я тут вспомнил из опыта, помогал одному предприятию апгрейдить ядро сети, и пока сотрудничал с ними, познакомился немного с внутренними их процессами, заодно познакомился с их программистом. Это был странный человек, который для внутренней информационной системы написал сам БД на php(!) и очень гордился этим. А интерфейс к этой системе писал тоже он. Интерфейс был так им "разработан", что обращался к бэкэнду довольно часто. В итоге имелась ситуация, что людям, которые работают с этой ИС запрещалось держать несколько окон открытыми, иначе происходило одно из двух - или браузер выжирал всю память или нагрузка на эту самую наколеночную БД сильно возрастала. Я не буду дальше продолжать список этой дичи, но я понял, что писать дичь в коде - это минимум того, что можно представить. Можно реализовывать дикие проекты с дичайшими нарушениями всех мыслимых рамок.
Первый случай настолько мудреный, что я не представляю где нужна такая конструкция. Но это опять же вопрос к тому кто писал, а не к языку
2,3 - ну это скорее непонимание того как это все работает в С
Про макросы - не вижу ничего плохо в макросах, если ими пользуются там где надо. Но, опять же, это не относится к самому языку, а к тому как написан конкретный код.
По всему списку, в итоге, вопросы к знаниям и навыкам того, кто создает конкретный код, а не к языку.
С какими-то моментами согласен с какими-то - нет. Но в целом, ведь, не только разработкой ограничивается вся деятельность в ИТ(в широком смысле этого слова). Автор, Вы возможно не нашли своего. Или может оно вообще не для Вас.
Не подумайте, что я пытаюсь выдивгать какие-то аргументы против Rust, но пока аргуементы в сторону безопасности выглядят весьма слабо, предполагая, что уже есть знания и опыт в С(т.е. понимание чего лучше не делать определенно). Кстати, просто желание попробовать себя в новом языке - это вполне аргумент.
Все хорошо, но в исследовании как-то учитывались индексы на таблицах? Ведь, токсичные запросы могут возникать когда нехватает или плохо построены индексы.
Хотя Linux и прочие ядра не написаны на Си, а на неком диалекте, в котором нет libc, есть ограничения на выделение памяти и прочие вещи, которые должны входить в Си.
Мне интересно откуда такая информация, что ядро Linux написано не на Си. Я когда изучал как устроен планировщик, я увидел уйму Си-кода.
И это вполне логично, что до того как ядро не инциировало кучу вещей, которые нужны для загрузки libc, ни о каком ее использовании не может быть и речи.
Не помню как ядро на ранних стадиях загрузки работает с прерываниями, но это правда, что там очень много ассемблера. В дальнейшем, обработка прерываний написана на Си.
Про ограничения памяти я не очень понял. Вы говорите про невозможность пользоваться верхней памятью? Не очень понимаю, почему Вы это пеняете непосредственно Си. Это ж вроде хардварные ограничения (вроде от режима процессора зависит, сейчас не помню)
Про автомобильную электронику не слышал, но вот станции управления лифтами как-то обходятся вообще без линкуса. Там чип(скорее всего FPGA) со своим микрокодом и хардварной таблицей настроек.
Да, это понятно. Сейчас лень искать уже эти файлы, но в каком-то случае может быть предупреждение, которое, впрочем, никак не повлияет на работоспособность кода. Но сегодня предпочитаю все же явно указывать приведение из void*, скорее для читабельности.
Спасибо, это ценное замечание. Не подумал об этом, но, наверно потому что не работал там где есть деливери ПО конечному пользователю. Но разве на других языках нет той же проблемы?
Вы бесконечно правы. Но не только со словом "нравственность" существует проблема, но и например со словом "справедливость". Я искал однажды во французском это слово, и вроде есть слова которые по значению рядом, но прям идеального совпадения не нашел. Мой преподаватель сказал, что также не знает точно перевода, который отображал бы именно русскоязычное понимание этого слова. Но тут как раз то, о чем я пишу в статье - язык это не только система символов, но это и система образов, язык накладывает сильнейший отпечаток на образы нашего мышления и на их возникновение. В качестве предположения, могу лишь сказать, что возможно европейские языки в меньшей степени склонны к акцентуации существущей в русском языке.
Когда что-то начинает менять жизнь человека, это уже вопрос не чисто теоретический, даже если исходить из "бытие определяет сознание". Когда тест Тьюринга будет пройден это станет еще большей проблемой.
На самом деле это касается не только pgsql. Я, например, часто статистику и аналитику тяну из кликхауса. И если на огромных таблицах не учитывать ключи и особенности работы самой СУБД, то можно получить запросы которые будут работать час. Конечно, в некоторых случаях их не избежать (типа bulk insert), но что касается того что отдается пользователю, то оно должно отдавать все же быстро и здесь разные критерии оценки. В этом смысле разделение на OLAP и OLTP дизайн для таблиц помогает.
Если запрос выполняется долго из-за того, что много данных - это проблема прежде всего индекса т.к. это означает, что в выборку по индексу попадает много данных, которые потом нужно еще группировать и фильтровать, а значит cardinality индекса очень низкий.
Если же вам нужно подключать много таблиц к запросу, то, вроде очевидно, что надо следить за планом запроса и использовать для JOIN поля с ключами и индексами. JOIN вообще самая медленная операция в РСУБД. Альтернативным путем иногда является переход на SELECT-driven модель, чтоб избежать JOIN'ов.
Но в любом случае получается, что задача сводится к анализу статистики запрсов и вытягиванию самых медленных. Затем их рефакторинг и получаем то, что надо.
Помню в году 2019, сижу на совещании на работе. Обсуждаем модернизацию одной из центральных площадок сети с техдиром. Рядом сидит мой стажер. Мне звонок по мобильнику. После смятого представления девушка наинает мне рассказывать про какую-то открытую вакансию. Я ее слушал порядка минуты а потом спросил откуда она. Она сказала "СберКлауд". Я тогда уточнил связано ли это как-то со Сбером, она ответила положительно. Тогда я ответил "А Сбербанк? Нет, спасибо. Меня такое не интересует, до свидания". Я видел как офигели коллеги от того что произошло и как они старались не смеяться. А я до сих пор не жалею о сделанном.
Да, я именно об этом.
Я когда-то очень давно (полагаю, что это было начало 2013 года), попал на JavaDay. Ну как...Начальник сказал записаться и пойти в порядке саморазвития. В общем, докладчик был из Одноклассников и рассказывал как они стартовали, как развивался код. Но поворотной точкой стал их выбор в сторону использованися Unsafe. Получается , рано или поздно все равно надо будет писать что-то что выходит за грани отведенной песочницы?
N.B. Я тут вспомнил из опыта, помогал одному предприятию апгрейдить ядро сети, и пока сотрудничал с ними, познакомился немного с внутренними их процессами, заодно познакомился с их программистом. Это был странный человек, который для внутренней информационной системы написал сам БД на php(!) и очень гордился этим. А интерфейс к этой системе писал тоже он. Интерфейс был так им "разработан", что обращался к бэкэнду довольно часто. В итоге имелась ситуация, что людям, которые работают с этой ИС запрещалось держать несколько окон открытыми, иначе происходило одно из двух - или браузер выжирал всю память или нагрузка на эту самую наколеночную БД сильно возрастала. Я не буду дальше продолжать список этой дичи, но я понял, что писать дичь в коде - это минимум того, что можно представить. Можно реализовывать дикие проекты с дичайшими нарушениями всех мыслимых рамок.
Первый случай настолько мудреный, что я не представляю где нужна такая конструкция. Но это опять же вопрос к тому кто писал, а не к языку
2,3 - ну это скорее непонимание того как это все работает в С
Про макросы - не вижу ничего плохо в макросах, если ими пользуются там где надо. Но, опять же, это не относится к самому языку, а к тому как написан конкретный код.
По всему списку, в итоге, вопросы к знаниям и навыкам того, кто создает конкретный код, а не к языку.
С какими-то моментами согласен с какими-то - нет. Но в целом, ведь, не только разработкой ограничивается вся деятельность в ИТ(в широком смысле этого слова). Автор, Вы возможно не нашли своего. Или может оно вообще не для Вас.
Вряд ли сейчас кто-то может предсказать будущее этой затеи. Надо смотреть на то, что дальше будет происходить с этой инициативой.
а где автор про него говорил?
Ровно также можно сказать, что материализм уже не оправдал себя.
Что Вами понимается под "откровенной дичью"?
Не подумайте, что я пытаюсь выдивгать какие-то аргументы против Rust, но пока аргуементы в сторону безопасности выглядят весьма слабо, предполагая, что уже есть знания и опыт в С(т.е. понимание чего лучше не делать определенно). Кстати, просто желание попробовать себя в новом языке - это вполне аргумент.
Да, сейчас отыскал эти файлы на флэшке. Я оказывается вообще убрал приведение.
Все хорошо, но в исследовании как-то учитывались индексы на таблицах? Ведь, токсичные запросы могут возникать когда нехватает или плохо построены индексы.
Мне интересно откуда такая информация, что ядро Linux написано не на Си. Я когда изучал как устроен планировщик, я увидел уйму Си-кода.
И это вполне логично, что до того как ядро не инциировало кучу вещей, которые нужны для загрузки libc, ни о каком ее использовании не может быть и речи.
Не помню как ядро на ранних стадиях загрузки работает с прерываниями, но это правда, что там очень много ассемблера. В дальнейшем, обработка прерываний написана на Си.
Про ограничения памяти я не очень понял. Вы говорите про невозможность пользоваться верхней памятью? Не очень понимаю, почему Вы это пеняете непосредственно Си. Это ж вроде хардварные ограничения (вроде от режима процессора зависит, сейчас не помню)
Про автомобильную электронику не слышал, но вот станции управления лифтами как-то обходятся вообще без линкуса. Там чип(скорее всего FPGA) со своим микрокодом и хардварной таблицей настроек.
Спасибо за подсказку с conan
Да, это понятно. Сейчас лень искать уже эти файлы, но в каком-то случае может быть предупреждение, которое, впрочем, никак не повлияет на работоспособность кода. Но сегодня предпочитаю все же явно указывать приведение из void*, скорее для читабельности.
Плюсы, Шарп, Раст, Джава?
Спасибо, это ценное замечание. Не подумал об этом, но, наверно потому что не работал там где есть деливери ПО конечному пользователю. Но разве на других языках нет той же проблемы?
Вы бесконечно правы. Но не только со словом "нравственность" существует проблема, но и например со словом "справедливость". Я искал однажды во французском это слово, и вроде есть слова которые по значению рядом, но прям идеального совпадения не нашел. Мой преподаватель сказал, что также не знает точно перевода, который отображал бы именно русскоязычное понимание этого слова. Но тут как раз то, о чем я пишу в статье - язык это не только система символов, но это и система образов, язык накладывает сильнейший отпечаток на образы нашего мышления и на их возникновение. В качестве предположения, могу лишь сказать, что возможно европейские языки в меньшей степени склонны к акцентуации существущей в русском языке.
О! Приятно увидеть статью, которая пересекается не только тематикой но и некоторыми общими пойнтами с твоей.
Это как-то меняет смысл в данном контексте?
Когда что-то начинает менять жизнь человека, это уже вопрос не чисто теоретический, даже если исходить из "бытие определяет сознание". Когда тест Тьюринга будет пройден это станет еще большей проблемой.