Функциональное программирование в примерах.
Язык Haskell: характеристики, история, сильные и слабые стороны, истории успеха и неудач.
Спецификация Haskell’98: синтаксис, компиляторы, интепретаторы, документация, IDE.
Особенности языка: тип Maybe, списки, классы типов, основы монад.
Библиотеки и фреймворки: Parsec, GenXml, HaXml
DSL
На десерт что-то из Existential Types, State Monad, ST Monad, Monad Transformers.
Доклад о дизайне кода в функциональном стиле на C++, представленный вниманию плюсовиков на C++ User Group Novosibirsk 2014.
В качестве демонстрационного проекта была реализована игра "Амбер" по мотивам "Хроник Амбера" Р. Желязны.
https://github.com/graninas/Amber
Функциональное программирование в примерах.
Язык Haskell: характеристики, история, сильные и слабые стороны, истории успеха и неудач.
Спецификация Haskell’98: синтаксис, компиляторы, интепретаторы, документация, IDE.
Особенности языка: тип Maybe, списки, классы типов, основы монад.
Библиотеки и фреймворки: Parsec, GenXml, HaXml
DSL
На десерт что-то из Existential Types, State Monad, ST Monad, Monad Transformers.
Доклад о дизайне кода в функциональном стиле на C++, представленный вниманию плюсовиков на C++ User Group Novosibirsk 2014.
В качестве демонстрационного проекта была реализована игра "Амбер" по мотивам "Хроник Амбера" Р. Желязны.
https://github.com/graninas/Amber
"Formal verification of C code" Efremov D.V.
The talk covers the issue of developing correct software applying one of the types of static code analysis. The speaker will also address the matters of using such methods, their weaknesses and limitations, as well as the results they can guarantee.
PHDays VII, PDUG section, Moscow, May 24 2017.
"Формальная верификация кода на языке Си" Ефремов Д.В.
Доклад посвящен разработке корректного программного обеспечения с применением одного из видов статического анализа кода. Будут освещены вопросы применения подобных методов, их слабые стороны и ограничения, а также рассмотрены результаты, которые они могут дать. На конкретных примерах будет продемонстрировано, как выглядят разработка спецификаций для кода на языке Си и доказательство соответствия кода спецификациям.
Доклад представлен на конференции PHDays VII (2017) 24 мая в секции PDUG.
Долгожданный релиз pg_pathman 1.0 / Александр Коротков, Дмитрий Иванов (Post...Ontico
Механизм секционирования в Postgres имеет ряд ограничений, которые не позволяют использовать концепцию секционирования в полной мере. Среди таких ограничений можно выделить неэффективность планирования запросов для секционированных таблиц (линейный рост времени планирования при увеличении количества секций), отсутствие HASH-секционирования, необходимость ручного управления секциями.
В нашем докладе мы расскажем про расширение pg_pathman, которое позволяет обойти эти ограничения. pg_pathman реализует RANGE и HASH секционирования с логарифмическим и константным временами планирования соответственно. В pg_pathman поддерживается определение секции на этапе выполнения, конкурентное секционирование.
pg_pathman долго находился в стадии beta-тестирования, но теперь мы рады, наконец, сообщить о релизе 1.0. В докладе мы расскажем как про детали внутреннего устройства, так и про приёмы практического использования.
Андрей Карпов
Вы узнаете, что такое статический анализ кода и историю его развития. Узнаете, как эффективно применять инструменты статического анализа в своей работе, увидите практические примеры использования этой методологии. Доклад ориентирован на программистов, использующих языки Си/Си++, но будет полезен всем
Улучшение качества открытого программного обеспечения с помощью инструментов ...Andrey Karpov
Одним из способов внести свой вклад в развитие открытого программного обеспечения, является поиск и исправление
различных программных ошибок и потенциальных уязвимостей. Достаточно просто, это можно осуществить, используя статические анализаторы кода. Это можно делать даже в том случае, если вы ещё мало знакомы с устройством работы проекта, но хотите внести вклад в его улучшение. Поговорим о методологии анализа исходного кода, бесплатных инструментах и автоматизации процессов проверки.
Запись доклада: https://youtu.be/-eUxbZ6W5Ig
Юрий Ефимочев, Компилируемые в реальном времени DSL для С++ Sergey Platonov
В последнее время в промышленной разработке ПО особую популярность обретают Domain-Specific Lanugages (DSL). Они драматически упрощают разработку и дают возможность “программировать” не только программистам, но и пользователям прикладных программ.
В своем докладе я расскажу об опыте использования DSL применительно к С++, причем упор будет сделан на производительность кода DSL, и его мгновенную “встраиваемость” в запущенную программу путем компиляции DSL-кода в нативный код с помощью инструментария LLVM.
Юлия Ковалёва. Fscheck — альтернативный путь для unit тестовMskDotNet Community
Как помочь тестам находить баги? Что лучше: каждый новый запуск на новом наборе данных или же стабильность? Как сделать тестовые данные эффективными?
В докладе рассматривается Property based подход для написания unit-тестов.
На реальных примерах будет показано то, какими возможностями обладает FsCheck в связке с C#, какие есть плюсы и минусы у данного инструмента и стоит ли тратить время на его изучение.
Tech Talks @NSU: Как приручить дракона: введение в LLVMTech Talks @NSU
http://techtalks.nsu.ru
Видеозапись: http://www.youtube.com/watch?v=v7uBLSm6ft8
06 октября 2015. Как приручить дракона: введение в LLVM (Дмитрий Кашицын, HDsoft)
«В этом докладе мы кратко расскажем о таком звере, о котором много кто слышал, но немногие щупали. Что такое компилятор на самом деле? Чем LLVM отличается от других компиляторов? Как в LLVM происходит компиляция программы, как работают оптимизации? Наконец, какой путь проходит программа от разбора исходного текста до генерации исполняемого файла?
Лекция будет обзорной и не потребует от слушателей глубоких знаний теории компиляторов.»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
10 июня 2015. Дмитрий Кашицын (HDsoft) дает обзор LLVM.
http://techtalks.nsu.ru
Видеозапись: https://plus.google.com/events/ctes98f7uhf19t5jlvlbk24dan4
В этом докладе мы кратко расскажем о таком звере, как LLVM, о котором много кто слышал, но немногие щупали. Что такое компилятор на самом деле? Чем LLVM отличается от других компиляторов? Как в LLVM происходит компиляция программы, как работают оптимизации? Наконец, какой путь проходит программа от разбора исходного текста до генерации исполняемого файла?
Лекция будет обзорной и не потребует от слушателей глубоких знаний теории компиляторов.
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
"Formal verification of C code" Efremov D.V.
The talk covers the issue of developing correct software applying one of the types of static code analysis. The speaker will also address the matters of using such methods, their weaknesses and limitations, as well as the results they can guarantee.
PHDays VII, PDUG section, Moscow, May 24 2017.
"Формальная верификация кода на языке Си" Ефремов Д.В.
Доклад посвящен разработке корректного программного обеспечения с применением одного из видов статического анализа кода. Будут освещены вопросы применения подобных методов, их слабые стороны и ограничения, а также рассмотрены результаты, которые они могут дать. На конкретных примерах будет продемонстрировано, как выглядят разработка спецификаций для кода на языке Си и доказательство соответствия кода спецификациям.
Доклад представлен на конференции PHDays VII (2017) 24 мая в секции PDUG.
Долгожданный релиз pg_pathman 1.0 / Александр Коротков, Дмитрий Иванов (Post...Ontico
Механизм секционирования в Postgres имеет ряд ограничений, которые не позволяют использовать концепцию секционирования в полной мере. Среди таких ограничений можно выделить неэффективность планирования запросов для секционированных таблиц (линейный рост времени планирования при увеличении количества секций), отсутствие HASH-секционирования, необходимость ручного управления секциями.
В нашем докладе мы расскажем про расширение pg_pathman, которое позволяет обойти эти ограничения. pg_pathman реализует RANGE и HASH секционирования с логарифмическим и константным временами планирования соответственно. В pg_pathman поддерживается определение секции на этапе выполнения, конкурентное секционирование.
pg_pathman долго находился в стадии beta-тестирования, но теперь мы рады, наконец, сообщить о релизе 1.0. В докладе мы расскажем как про детали внутреннего устройства, так и про приёмы практического использования.
Андрей Карпов
Вы узнаете, что такое статический анализ кода и историю его развития. Узнаете, как эффективно применять инструменты статического анализа в своей работе, увидите практические примеры использования этой методологии. Доклад ориентирован на программистов, использующих языки Си/Си++, но будет полезен всем
Улучшение качества открытого программного обеспечения с помощью инструментов ...Andrey Karpov
Одним из способов внести свой вклад в развитие открытого программного обеспечения, является поиск и исправление
различных программных ошибок и потенциальных уязвимостей. Достаточно просто, это можно осуществить, используя статические анализаторы кода. Это можно делать даже в том случае, если вы ещё мало знакомы с устройством работы проекта, но хотите внести вклад в его улучшение. Поговорим о методологии анализа исходного кода, бесплатных инструментах и автоматизации процессов проверки.
Запись доклада: https://youtu.be/-eUxbZ6W5Ig
Юрий Ефимочев, Компилируемые в реальном времени DSL для С++ Sergey Platonov
В последнее время в промышленной разработке ПО особую популярность обретают Domain-Specific Lanugages (DSL). Они драматически упрощают разработку и дают возможность “программировать” не только программистам, но и пользователям прикладных программ.
В своем докладе я расскажу об опыте использования DSL применительно к С++, причем упор будет сделан на производительность кода DSL, и его мгновенную “встраиваемость” в запущенную программу путем компиляции DSL-кода в нативный код с помощью инструментария LLVM.
Юлия Ковалёва. Fscheck — альтернативный путь для unit тестовMskDotNet Community
Как помочь тестам находить баги? Что лучше: каждый новый запуск на новом наборе данных или же стабильность? Как сделать тестовые данные эффективными?
В докладе рассматривается Property based подход для написания unit-тестов.
На реальных примерах будет показано то, какими возможностями обладает FsCheck в связке с C#, какие есть плюсы и минусы у данного инструмента и стоит ли тратить время на его изучение.
Tech Talks @NSU: Как приручить дракона: введение в LLVMTech Talks @NSU
http://techtalks.nsu.ru
Видеозапись: http://www.youtube.com/watch?v=v7uBLSm6ft8
06 октября 2015. Как приручить дракона: введение в LLVM (Дмитрий Кашицын, HDsoft)
«В этом докладе мы кратко расскажем о таком звере, о котором много кто слышал, но немногие щупали. Что такое компилятор на самом деле? Чем LLVM отличается от других компиляторов? Как в LLVM происходит компиляция программы, как работают оптимизации? Наконец, какой путь проходит программа от разбора исходного текста до генерации исполняемого файла?
Лекция будет обзорной и не потребует от слушателей глубоких знаний теории компиляторов.»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
10 июня 2015. Дмитрий Кашицын (HDsoft) дает обзор LLVM.
http://techtalks.nsu.ru
Видеозапись: https://plus.google.com/events/ctes98f7uhf19t5jlvlbk24dan4
В этом докладе мы кратко расскажем о таком звере, как LLVM, о котором много кто слышал, но немногие щупали. Что такое компилятор на самом деле? Чем LLVM отличается от других компиляторов? Как в LLVM происходит компиляция программы, как работают оптимизации? Наконец, какой путь проходит программа от разбора исходного текста до генерации исполняемого файла?
Лекция будет обзорной и не потребует от слушателей глубоких знаний теории компиляторов.
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
PostgreSQL: практические примеры оптимизации SQL-запросов / Иван Фролков (Po...Ontico
Довольно часто как адинистраторы, так и разработчики жалуются на низкую производительность приложений, работающих с базой данных, и нередко при этом ищут решения возникших проблем с помощью различных настроек как СУБД, так и операционной системы, пренебрегая при этом самым действенным способом - оптимизацией запросов к собственно БД.
Тому, как понимать, где же узкие места, и как их можно попробовать избежать на примере PostgreSQL и посвящен этот доклад.
Alasql.js - SQL база данных на JavaScript / Андрей Гершун (МАГ КОНСАЛТИНГ)Ontico
AlaSQL - это библиотека для обработки данных с помощью языка SQL, которая написана на JavaScript и может работать в браузере (в том числе, и в режиме WebWorker) или Node.js. Библиотека может быть использована в приложениях для обработки данных, а также для решения задач ETL (extract-transform-loading), таких как приложения бизнес-аналитики.
Тезисы - http://frontendconf.ru/2015/abstracts/1713
AlaSQL - SQL библиотека на JavaScript (выступление на PiterJS)Andrey Gershun
AlaSQL - это библиотека для обработки данных с помощью языка SQL, которая написана на JavaScript и может работать в браузере (в том числе, и в режиме WebWorker) или Node.js. Библиотека может быть использована в приложениях для обработки данных, а также для решения задач ETL (extract-transform-loading), таких как приложения бизнес-аналитики.
AlaSQL позволяет проводить сложные манипуляции с массивами данных (такие как группировки, сортировки, выборки, слияния) с помощью привычных выражений языка SQL. Встроенные процедуры импорта и экспорта данных в различных форматах (включая TXT, JSON, CSV, TSV, Microsoft Excel и Google Spreadsheets) предоставляют удобный интерфейс для импорта и экспорта прямо из SQL-выражений. Библиотека хорошо сочетается с такими современными фреймворками, как Angular.js, d3.js и Google Chars.
AlaSQL поддерживает совместимость по многим операторам со стандартным SQL и различными его диалектами, что позволяет переносить ранее разработанные процедуры для других баз данных. Специальные расширения синтаксиса SQL позволяют простым и удобным способом использовать все возможности, предоставляемые JavaScript, например, обработка JSON объектов из SQL выражений.
Для достижения высокого быстродействия AlaSQL написана с использованием сильно оптимизированного JavaScript и содержит несколько эвристик для сокращения времени обработки SQL выражений.
Современный статический анализ кода: что умеет он, чего не умели линтерыcorehard_by
Статический анализ появился почти 40 лет назад. В своём докладе мы хотим показать, чему за это время научились статические анализаторы. Мы рассмотрим различные методики анализа, как они появлялись и какие ошибки можно найти с помощью них. Посмотрим на примеры ошибок, найденных PVS-Studio в Open Source проектах. Поговорим о том, чем статический анализатор отличается от "линтеров" и некоторых других инструментов, а также какие проблемы решает современный статический анализатор C++ кода, помимо собственно анализа кода.
Павел Беликов
@PVS-Studio, Тула, Россия
Scala-библиотека Slick прекрасно зарекомендовала себя как развитый и удобный инструмент работы с базами данных. Поддерживаются и простейшие текстовые SQL-запросы, и строго типизированные join’ы нескольких таблиц. Для построения запросов Slick предоставляет DSL, код на котором выглядит как обработка коллекций. Причем простые подзапросы могут использоваться для конструирования более сложных.
Slick имеет весьма любопытную внутреннюю архитектуру, которая делает возможным не только продвинутое использование, но и расширение библиотеки несколькими способами, о которых и пойдет речь в докладе.
(see also video: https://youtu.be/9n1zzwOGado)
Опыт разработки статического анализатора кодаAndrey Karpov
Один из основателей проекта PVS-Studio расскажет об опыте разработки статического анализатора кода C++. У инструментов статического анализа кода существует "проблема айсберга". От пользователей скрыты сложные механизмы анализа кода, и иногда им кажется, что статические анализаторы – это просто какие-то утилиты, ищущие опечатки с помощью регулярных выражений. Автор доклада постарается в общих чертах описать, как всё обстоит на самом деле. Он покажет на примерах, почему нормальный анализ с помощью регулярных выражений нереализуем, что такое Data Flow анализ, а также расскажет о других технологиях, применяемых при анализе кода. Вкратце будет затронут вопрос использования нейронных сетей, обсуждение которых сейчас является очень модной темой, и рассказано, почему с точки зрения анализа кода отношение к этому направлению является очень скептическим.
Доклад посвящен разработке корректного программного обеспечения с применением одного из видов статического анализа кода. Будут освещены вопросы применения подобных методов, их слабые стороны и ограничения, а также рассмотрены результаты, которые они могут дать. На конкретных примерах будет продемонстрировано, как выглядят разработка спецификаций для кода на языке Си и доказательство соответствия кода спецификациям.
2. МЫ РАССМОТРИМ
● Основные моменты работы с РБД
● Что такое EXPLAIN и как с ним работать
● Индексы и их особенности
● Лайфхаки и хитрости
3. Основы работы с РБД
● Запись в таблице должна соответствовать объекту
● Правильно выбрать уровень нормализации
● Уделить немало времени на проектирование
● Структура БД должна быть гибкой
● Простота в поддержке жизненого цикла БД
● Правильно расставлять индексы,
не создавать бардак
● Строить запросы не выбирая все подряд (*),
только необходимое
● Приступать к оптимизации, когда действительно это
требуется
4. ORM vs SQl
●
ORM — удобно?
●
ORM — быстро?
Total runtime: (~)117.092 ms*
JAVA
@ManyToOne
@JoinColumn(name = "CATEGORY_ID")
public Category getCategory() {
return category;
}
PHP
$customers = Customer::find()
->where(['status' => TRUE])
->orderBy('id')
->limit(100, 10000);
* Подробный пример мы разберем ниже
☑
5. ORM vs SQL
●
SQL — удобно?
●
SQL — быстро?
Total runtime: (~)11.926 ms
SELECT * FROM (
SELECT * FROM posts
WHERE author = 'nick'
ORDER BY posts.publish
DESC LIMIT 10
) as posts
JOIN post_category
ON posts.category_id = category.id
ORDER BY posts.publish DESC LIMIT 10;
☒
* Подробный пример мы разберем ниже
6. Еще об ORM
● Позволяет представить запись в БД в виде объекта
● Удобнее понимать и легче писать чем SQL
● Поддержка и изменения не вызывают трудностей
● Сложные запросы иногда невозможно написать
● Трудно оптимизировать
● Иногда строится запрос, который не использует
индексы
7. А что с SQL?
● Сложные выборки, запросы
● Возможности оптимизации
● Функции и различные возможности SQL
● HighLoad — однозначно SQL (узкое место)
● Запрос с использованием индексов не всегда быстрый
● Замусоривает код (JAVA и многострочные литералы)
● Нет проверок на этапе компиляции
8.
9. ANALYZE
ANALYZE считывается определённое количество
строк таблицы в базе данных, выбранных случайным
образом, и сохраняет результаты в системном
каталоге pg_statistic.
Затем планировщик запросов будет использовать эту
статистику для выбора эффективных планов
запросов.
=> ANALYZE VERBOSE;
WARNING: skipping "pg_statistic" --- only superuser or database owner can analyze it
WARNING: skipping "pg_type" --- only superuser or database owner can analyze it
INFO: analyzing "public.test"
INFO: "test": scanned 16669 of 16669 pages, containing 2000200 live rows
and 0 dead rows; 30000 rows in sample, 2000200 estimated total rows
10. VACUUM
● Очистка места (помечание), занимаемое
«мертвыми» кортежами
● По-умолчанию очищает все таблицы доступные
пользователю
● Без опции FULL может работать параллельно,
т. к. не требует исключительной блокировки
● With FULL работает медленно, требует блокировки
и возвращает освобожденное место операционной
системе.
● Autovacuum — демон очистки (VACUUM+ANALYZE)
● ! table bloating
11.
12. Таблица TEST
=> CREATE TABLE test (id integer, text text);
=> INSERT INTO test
SELECT id, md5(random()::text)
FROM generate_series(1, 1000000) AS id;
=> d test
Table "public.test"
Column | Type | Modifiers
----------------+------------+-----------
column_1 | integer |
column_2 | text |
13. => EXPLAIN SELECT * FROM test;
● Cost — у.е. для оценки затратности
операции.
1ое значение — затраты доступа к 1й строке
2ое значение — затраты для доступа ко
всем строкам.
● Rows — (~) количество строк при вызове
Seq Scan к этой таблице
● With — длина строки в байтах
14. Всё, что мы видели выше в выводе команды EXPLAIN —
ожидания планировщика.
=> EXPLAIN (ANALYZE) SELECT * FROM test;
● Actual time — реальное время в миллисекундах для
1ой и всех строк
● Rows — реальное количество строк полученных
● Loops — количество выполнений данной операции
● Plannig time — время выполнения EXPLAIN
● Execution time — общее время выполнения
● Heap Fetches — число реальных обращений к таблице
!!! DANGER !!!
EXPLAIN (ANALYZE) исполняет команды
15. => EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM test;
● Buffers: shared read — количество блоков
считанных с диска;
● Buffers: shared hit — количество блоков,
считанных из кэша PostgreSQL.
CACHE
16. WHERE
=> EXPLAIN (ANALYZE)
SELECT * FROM test WHERE id
between 1500 and 1550;
● Индексов нет поэтому Seq Scan
● Каждая строка сравнивается с:
Filter: ((id >= 1500) AND (id <= 1550))
● Cost увеличилось
● Rows уменьшилось до ождаемого количества
Execution time: 222.979 ms
17. Index Scan
=> CREATE INDEX ON test(id);
=> EXPLAIN (ANALYZE)
SELECT * FROM test WHERE id
between 1500 and 1550;
● Теперь Index Scan using test_id_idx on test;
● Index Cond: ((id >= 1500) AND (id <= 1550))
Execution time: 0.127 ms
18. Seq Scan
A C D
1) С < 10
2) С < 10
3) С < 10
С < 10
20. ИНДЕКСЫ
● Но что будет, если поменять условие
=> EXPLAIN (ANALYZE)
SELECT * FROM test WHERE id > 1550;
● Теперь Seq Scan on test
● Пришлось прочитать все строки, кроме
первых 1500..
● Время увеличилось, что не удивительно
Execution time: 678.852 ms
21. ИНДЕКСЫ
● А если выключить Seq Scan
=> SET enable_seqscan TO off;
● Теперь Index Scan using test_id_idx on test
● Но время запроса стало еще больше
Execution time: 749.952 ms
● И стоимость cost также увеличилась
Планировщик не дурак =)
22. Про индексы
● Индекс это дополнительная структура
данных (не SQL)
● Индексы требуют затраты на поддержание
● Замедляют обновление
● Замедляют репликацию
● Малая селективность — неэфективно
Индексы не панацея!
23. Index Only Scan
● EXPLAIN (ANALYZE)
SELECT id FROM test WHERE id < 450;
● Index Only Scan using test_id_idx on test
● Выбираем только поле id,
чтобы включить IOS
● Скорость очень большая
Execution time: 0.659 ms
25. ИНДЕКСЫ ПО ТЕКСТУ
EXPLAIN (ANALYZE)
SELECT * FROM test WHERE text LIKE 'ab%';
● Seq Scan
After CREATE INDEX ON test(text);
● Также Seq Scan (211 ms), потому что UTF-8!
● Нужно использовать класс оператора
text_pattern_ops
CREATE INDEX ON test(text text_pattern_ops);
26. ИНДЕКСЫ ПО ТЕКСТУ
EXPLAIN (ANALYZE)
SELECT * FROM test WHERE text LIKE 'ab%';
● Bitmap Index Scan on test_text_idx1
● Сравниваем
Index Cond: (
(text ~>=~ 'ab'::text) AND (text ~<~ 'ac'::text)
)
● Далее Bitmap Heap Scan on test
проверяет существуют ли записи на самом
деле
28. Создание индексов
● Требуют блокировки при создании
● CONCURRENTLY создает в фоне, но долго (требует
2 прохода)
● Можно и нужно мониторить неиспользуемые
индексы (расходуются рессурсы и время)
● Можно находить дубликаты индексов
● Можно строить индексы по функциям, но
необходимо точное её повторение при запросе
● ! index bloating
29. Когда создавать индексы?
CREATE TABLE test5 (id integer PRIMARY KEY, v float8);
ACREATE INDEX test5_v_idx ON test5(v);
INSERT INTO test5
(SELECT id, random() FROM generate_series(1,1000000) id);
CREATE TABLE test5 (id integer PRIMARY KEY, v float8);
BINSERT INTO test5
(SELECT id, random() FROM generate_series(1,1000000) id);
CREATE INDEX test5_v_idx ON test5(v);
30. Когда создавать индексы?
CREATE TABLE a (id integer PRIMARY KEY, v float8); 1,991 ms
CREATE INDEX a_v_idx ON a(v); 0,506 ms
INSERT INTO a
(SELECT id, random() FROM
generate_series(1,1000000) id);
4909,127 ms
A = Total: 4911 ms
CREATE TABLE b (id integer PRIMARY KEY, v float8); 1,990 ms
INSERT INTO b
(SELECT id, random() FROM
generate_series(1,1000000) id);
938,852 ms
CREATE INDEX b_v_idx ON b(v); 1195,492 ms
B = Total: 2136 ms
32. Мониторим неиспользуемые индексы
SELECT schemaname || '.' || relname AS table, indexrelname AS index,
pg_size_pretty(pg_relation_size(i.indexrelid)) AS index_size, idx_scan as
index_scans
FROM pg_stat_user_indexes ui
JOIN pg_index i ON ui.indexrelid = i.indexrelid
WHERE NOT indisunique AND idx_scan < 50 AND pg_relation_size(relid) > 5 * 819
ORDER BY pg_relation_size(i.indexrelid) / nullif(idx_scan, 0) DESC NULLS FIRST,
pg_relation_size(i.indexrelid) DESC;
table | index | index_size | index_scans
---------------------+---------------------------+---------------+-------------
public.test | test_text_idx | 56 MB | 0
public.test5 | test5_v_idx | 28 MB | 0
public.test6 | test6_v_idx | 21 MB | 0
public.test | test_text_idx1 | 56 MB | 3
public.test | test_id_idx | 21 MB | 36
33. Ищем дубликаты индексов
lk=> SELECT pg_size_pretty(SUM(pg_relation_size(idx))::BIGINT) AS SIZE,
(array_agg(idx))[1] AS idx1, (array_agg(idx))[2] AS idx2,
(array_agg(idx))[3] AS idx3, (array_agg(idx))[4] AS idx4
FROM ( SELECT indexrelid::regclass AS idx,
(indrelid::text ||E'n'|| indclass::text ||E'n'|| indkey::text ||E'n'||
COALESCE(indexprs::text,'')||E'n' || COALESCE(indpred::text,'')) AS KEY
FROM pg_index) sub
GROUP BY KEY HAVING COUNT(*)>1
ORDER BY SUM(pg_relation_size(idx)) DESC;
size | idx1 | idx2 | idx3 | idx4
---------+-----------------------+----------------------+------+------
32 kB | blocks_id_idx | blocks_id_idx1 | |
32 kB | blocks_type_idx1 | blocks_type_idx | |
32 kB | primary_key | ids | |
34. Оптимизация OFFSET
Ситуация:
SELECT …
FROM table1
JOIN table2 using (table2id)
JOIN table3 using (table3id)
WHERE
набор условий ТОЛЬКО по table1
Order by (набор полей table1) LIMIT ... OFFSET ...
Важно: сработает если соблюдается условие, что
логика выборки и offset реализуется в table1, а также
что присоединенные данные из таблиц table2 и table3
на запрос не влияют.
35. EXPLAIN ANALYZE
SELECT * FROM test
JOIN vals ON vals.test_id = test.id
WHERE val between 150 AND 9500
LIMIT 5 OFFSET 5000;
Execution time: 283.471 ms
EXPLAIN ANALYZE
SELECT * FROM ( SELECT * FROM test
WHERE val between 150 AND 9500
LIMIT 5 OFFSET 5000) AS test
JOIN vals ON vals.test_id = test.id;
Execution time: 4.079 ms
36. Оптимизация COUNT(*)
=> EXPLAIN ANALYZE SELECT count(*) FROM
cache_customers_rates;
Execution time: 18632.959 ms
=> EXPLAIN ANALYZE SELECT
(reltuples)::numeric FROM pg_class r WHERE
relkind='r' AND relname='cache_customers_rates';
Execution time: 0.079 ms
37. Получение строк в виде ROW
=> SELECT * FROM tasks;
id | type | status | params | out. | exc.
----+---------------+---------+------------------+------+-----
1 | refill_cache | new | {"threads":-1} | |
2 | refill_cache | new | {"threads":-1} | |
=> SELECT tasks FROM tasks;
tasks
--------------------------------------------------------------------
( 1, refill_cache, new, "{""threads"":-1}", "", "" )
( 2, refill_cache, new, "{""threads"":-1}", "", "" )
38. Получение строк в виде JSON
=> SELECT row_to_json(tasks) FROM tasks;
row_to_json
-----------------------------------------------------------------
{
"id":1,
"type":"refill_cache",
"status":"new",
"params":"{"threads":-1}",
"output":"",
"exception":""
}
39. Выбранные поля в виде JSON
=> SELECT row_to_json( t ) FROM ( SELECT id,
type FROM tasks) AS t;
row_to_json
------------------------------------------------
{ "id":1, "type":"refill_cache" }
{ "id":1, "type":"refill_cache" }