title

text

Андрей Бородин
Андрей Бородин Яндекс Разработчик
Александр Каленик
Александр Каленик Kontur Software Engineer
: декабря
22 мин

Как мы ускорили GiST. Новости PostGIS 3.2

В докладе я расскажу о новом методе для быстрого создания GiST индекса в PostgreSQL 14, какие проблемы были выявлены при добавление поддержки нового метода в PostGIS и как они будут решены в будущем. Так же в докладе будет обзор нововведений PostGIS 3.2.

Слайды

Видео

Видео доступно участникам мероприятия, выполнившим вход в личный кабинет

Другие доклады

  • Иван Чувашов
    Иван Чувашов ООО Calltouch DBA
    22 мин

    Повреждение данных PostgreSQL на жестком диске. Что делать и как исправить?

    Любая СУБД хранит свои данные на жестком диске, следовательно, может произойти ситуация, когда данные на диске повредились. Это может быть сбой контроллера, логическое или физическое повреждение данных, есть и масса других причин. Хорошо, когда в таких ситуациях повреждается файл индекса, команда пересоздания индекса позволяет восстановить консистентность в СУБД. Гораздо хуже дело обстоит, когда поврежден файл таблицы или системного раздела, восстановить поврежденные данные тогда невозможно. Приходиться прибегать к разным ухищрениям. Это может быть восстановление из бекапа, копирование данных из поврежденной таблицы или другие способы. В докладе рассмотрим несколько случаев повреждения данных на диске и опишем варианты восстановления данных из поврежденных таблиц.

  • Вадим Яценко
    Вадим Яценко Tantor Lab Генеральный директор
    45 мин

    Autovacuum. Вредные советы

    В архитектуре PostgreSQL есть ряд особенностей, которые стоит учитывать не только при эксплуатации БД, но и в процессе проектирования схемы данных. Опытным пользователям PostgreSQL хорошо известен такой механизм как очистка/заморозка(vacuum). На просторах интернета есть большое количество материалов на тему внутреннего устройства, настройки и мониторинга. Множество полезных докладов было сделано на конференциях. Тем не менее, все еще происходят случаи переполнения счетчика транзакций(xid), казалось бы, в достаточно небольших БД. В этом докладе я расскажу об одном интересном, на мой взгляд, случае у нашего клиента. Поделюсь тем, как череда ошибок на разных этапах жизненного цикла БД, однажды привела к ее полной остановке более чем на неделю, wraparound-у, битым блокам, проблемам с обслуживанием и бессонным ночам в поисках решения. Локальная победа была достигнута - БД удалось восстановить, но история еще не закончена. Тем она и интересна.

  • Анастасия Волкова
    Анастасия Волкова DBeaver JAVA developer
    22 мин

    Babelfish: PostgreSQL с поддержкой SQL Server

    Задачи миграции с классических коммерческих БД на open-source решения по-прежнему актуальны. Решения для миграции Oracle приложений на PostgreSQL уже хорошо себя зарекомендовали. Но что делать если у вас SQL Server? Хотим вам представить Babelfish - базирующийся на PostgreSQL 13 open source проект. Babelfish поддерживает сетевой протокол TDS, язык T-SQL и специфичные для SQL Server расширения SQL. Однако не всё так просто. Про особенности совместимости с SQL Server, проблемы и способы их решения мы расскажем в этом докладе. Бонус: история про то как мы добавляли поддержку Babelfish в DBeaver, используя JDBC драйвер от Microsoft.

  • Анатолий Анфиногенов
    Анатолий Анфиногенов АО "ВНИИЖТ" Зам. директора научного центра - начальник отдела разработки ПО
    45 мин

    Жизнь после импортозамещения: некоторые особености настройки БД и хранимых процедур

    Многие литературные произведения заканчиваются свадьбой, а про дальнейшую жизнь героев читателю скупо сообщают, что они жили долго и счастливо. В 2019 распределенное серверное приложение, работающего 24/7 на полигоне 16 железных дорог от Калининграда до Хабаровска плюс несколько БД центрального уровня, было перенесено с Oracle 11g SE на ванильный PostgreSQL 11.9. Но наша история не закончилась на успешном импортозамещении - жизнь продолжалась и порой преподносила сюрпризы. Мы столкнулись с некоторым количеством эксплуатационных проблем, часть из которых удалось решить за счет реорганизации данных, часть - за счет изменения хранимых процедур, а еще часть - за счет изменения парамеров PostgreSQL. Решение наших проблем было бы невозможным без встроенной в приложение системы логирования и профилирования. Доклад посвящен примерам успешного диагностирования и решения проблем с производительностью приложения для БД PostgreSQL, все взаимодействие с которым осуществляется только через слой хранимых процедур.