Отдельное спасибо, даже не спасибо, а отдельная благодарность за проект на github, очень интересный проект, буду изучать, может быть удастся что то привнести свое.
Лучший доклад всей конференции, я конечно где то 30% посмотрел докладов, но большинство мягко говоря остой. Не думаю что дальше будет лучше. Тут прям очень приятно и интересно, большой опыт работы с ТЖ, все что говорит докладчик правильно плюс кое что подчерпнул новое, не зря время потратил. И презентация видно что хорошо сделана. Наработки на гитхабе вообще для меня лично бесцены, несколько раз подходил к ES но не получалось воспользоваться. Повезло коллегам Максима, думаю приятно работать с таким специалистом.
Пересмотрел еще раз и не пойму на 34:20 почему отмена транзакции 9,5 секунд? Обычно же фиксируется время выполнения операции. Трназакция у нас установилась за 0, потом работал код 1С не имеющий вообще отношения к СУБД, потом мы откатываем транзакцию, я ожидал там увидеть 0. Т.е. например с hold понятно мы вошли в серверный сеанс, в момент первого запроса к СУБД (установка транзакции) захватили соединение, затем не важно что там происходило, при завершении серверного вызова мы освобождаем сеанс. Всего занимали его 9,5 секунд. Но почему отмена транзакции пишет не время потраченное на отмену а время жизни отменяемой транзакции не пойму. Как тогда будет выглядеть событие отмены если мы например 10 минут писали данные, а потом решили отменить транзакцию и PG еще 1 минуту чистил журнал? Я ожидал увидеть там одну минуту. Нет ли у вас тут ошибки?
Извиняюсь за "некропостинг", но могу сказать, что: ошибки нет, сеанс все это время удерживал соединение с СУБД и, в итоге, откатил транзакцию. Смысл в том, что не само событие отката транзакции заняло 9,5 секунд, в удержание соединения с СУБД заняло 9,5 секунд. Сколько за это время мог накопить блокировок сеанс в рамках этого соединения - неизвестно. В докладе был примитивный пример, но суть должна быть понятна: длительные события SDBL с rollback transaction, это потенциальное зло
![LAVROV's interview with Tucker CARLSON 😁 [Parody]](http://i.ytimg.com/vi/mbMemqc-QEk/mqdefault.jpg)
Доклад огонь) Спикер ТОП)
Отдельное спасибо, даже не спасибо, а отдельная благодарность за проект на github, очень интересный проект, буду изучать, может быть удастся что то привнести свое.
Лучший доклад всей конференции, я конечно где то 30% посмотрел докладов, но большинство мягко говоря остой.
Не думаю что дальше будет лучше.
Тут прям очень приятно и интересно, большой опыт работы с ТЖ, все что говорит докладчик правильно плюс кое что подчерпнул новое, не зря время потратил.
И презентация видно что хорошо сделана.
Наработки на гитхабе вообще для меня лично бесцены, несколько раз подходил к ES но не получалось воспользоваться.
Повезло коллегам Максима, думаю приятно работать с таким специалистом.
Пересмотрел еще раз и не пойму на 34:20 почему отмена транзакции 9,5 секунд?
Обычно же фиксируется время выполнения операции. Трназакция у нас установилась за 0, потом работал код 1С не имеющий вообще отношения к СУБД, потом мы откатываем транзакцию, я ожидал там увидеть 0.
Т.е. например с hold понятно мы вошли в серверный сеанс, в момент первого запроса к СУБД (установка транзакции) захватили соединение, затем не важно что там происходило, при завершении серверного вызова мы освобождаем сеанс. Всего занимали его 9,5 секунд.
Но почему отмена транзакции пишет не время потраченное на отмену а время жизни отменяемой транзакции не пойму.
Как тогда будет выглядеть событие отмены если мы например 10 минут писали данные, а потом решили отменить транзакцию и PG еще 1 минуту чистил журнал?
Я ожидал увидеть там одну минуту. Нет ли у вас тут ошибки?
Извиняюсь за "некропостинг", но могу сказать, что: ошибки нет, сеанс все это время удерживал соединение с СУБД и, в итоге, откатил транзакцию. Смысл в том, что не само событие отката транзакции заняло 9,5 секунд, в удержание соединения с СУБД заняло 9,5 секунд. Сколько за это время мог накопить блокировок сеанс в рамках этого соединения - неизвестно. В докладе был примитивный пример, но суть должна быть понятна: длительные события SDBL с rollback transaction, это потенциальное зло
Автор пересказал нам то, что рассказывают на курсе "Применение методик." Мог бы и ссылку дать.