69753

Во

https://pastebin.com/YjrEkj0j

Ваш план

Использует индекс CREATE INDEX i_countrylanguage ON countrylanguage USING btree (countrycode);

А нет. простите. преждевременно

https://pastebin.com/A3t7AWgJ

ну да, в мускле index-only scan. только extended в explain уже можно не писать, оно автоматом делается

В дампе 2 таблицы

Вернусь, проверю.

Нет таблицы country

Странно.

Нет таблицы country

извиняюсь. опечатался в названии таблиы для дампа и дампер не выдал предупреждения.

Тут существенно улучшить конечно не получится. Думаю под конкретно этот запрос строить индекс типа create index on countrylanguage (language , countrycode) ; (аналог первичного ключа в этой таблице) безсмысленно. Но вот немного странно, что у меня план дает 1 секунду время выполнения у вас аж 4.... на таких объемах размер ram не играет значения. Интересно на чем вы выполняете запросы.

http://ps.tmpc.ru/927f532d

У меня правда pg - 9.6

пока постгрес свои хэш-джойны развернёт, мускуль по-быстрому на индекс сканах вжух?

Я слабо представляю, что творится у мускуля внутри. Но видимо да - магия

любой планировщик ошибается, вот и вся магия. для этого придумали хинты. а, ну да... :)

любой планировщик ошибается, вот и вся магия. для этого придумали хинты. а, ну да... :)

Опять по больному месту? )) Хотя я против хинтов

да нет, я даже не вникал, если честно, просто мимо крокодил

С изменением объема данных - хинты могут подсказывать неправильно... и пару раз это становилось головной болью с oracle

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

да и все косты вот эти — мы же понимаем, что это очень условные величины

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

Тут существенно улучшить конечно не получится. Думаю под конкретно этот запрос строить индекс типа create index on countrylanguage (language , countrycode) ; (аналог первичного ключа в этой таблице) безсмысленно. Но вот немного странно, что у меня план дает 1 секунду время выполнения у вас аж 4.... на таких объемах размер ram не играет значения. Интересно на чем вы выполняете запросы.

AMD-FX6300

мой локалхост

У меня правда pg - 9.6

разницы на тестовой программе не было вообще. с 10м

У меня для сравнения в контейнере, на виртуалке, в цоде делением ядер 1:5. И время выполнения 1 секунда

да и все косты вот эти — мы же понимаем, что это очень условные величины

у оракла они заметно более точные. у пг весьма приблизительные по сути

У меня для сравнения в контейнере, на виртуалке, в цоде делением ядер 1:5. И время выполнения 1 секунда

не скажу за деление ядер, но остальное перечисленное практически не играет роли. к тому же, мыскл и пг в равных хардваре условиях

у оракла они заметно более точные. у пг весьма приблизительные по сути

всё равно же эвристика. где-то умнее, где-то так себе

у оракла они заметно более точные. у пг весьма приблизительные по сути

Планы не так точны - у оракла очень много информации - статистики - вот это да - отлично

что интересно, у оракла с 11й версии появился "автооптимизатор", который по факту исполнения запроса вычисляет ошибки планировщика и исправляет их для следующего запроса

круто, да. но даже он вряд ли учитывает промахи в CPU cache, фрагментацию файлов на диске, и т.д.

вобщем, если мне покажете, что на отличном от моего железе пг работает на этой задаче быстрее мыскуля — я буду рад и спокоен как слоник

круто, да. но даже он вряд ли учитывает промахи в CPU cache, фрагментацию файлов на диске, и т.д.

ну он не сразу, он статистику ошибок оптимизатора ведёт, чтобы точнее исправлять

я понимаю

ну и насколько я помню там можно как то это профилями что ли управлять, чтобы когда тебе известен профиль нагрузки на сервер, то можно было их переключать. за давностью лет подзабыл уже

что интересно, у оракла с 11й версии появился "автооптимизатор", который по факту исполнения запроса вычисляет ошибки планировщика и исправляет их для следующего запроса

Это вы про автотюнинг? Который еще рекомендации дает - у вас тут индекса нет, а тут бы параллелизма накинуть?

Это вы про автотюнинг? Который еще рекомендации дает - у вас тут индекса нет, а тут бы параллелизма накинуть?

да

Ну он достаточно глуп. Профили да есть - ими можно для конкретного запроса - прибить ту же степень параллелизма. Но есть одно условие - надо всегда использовать биндинг переменных - иначе оракл будет считать каждую версию - разным запросом

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

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

перескажите вкратце?

минутку

Ну он достаточно глуп. Профили да есть - ими можно для конкретного запроса - прибить ту же степень параллелизма. Но есть одно условие - надо всегда использовать биндинг переменных - иначе оракл будет считать каждую версию - разным запросом

биндинг очевидно и так используется.

лан, всем сн

перескажите вкратце?

вот он: https://www.osp.ru/netcat_files/userfiles/TBD_2_2017/Rivkin_tbd_17.pdf

Automatic SQL Tuning (Tuning Advisor) вот о чем выше речь шла.

да, но они там в 18c наворотили ещё кучу всего поверх

как-то раз меня занесло на Oracle Open World. ушёл просветлённым...

)) Самый опытный Oracle DBA в нашей организации даже автоматическое управление памятью СУБД не доверяет (до 11 версии было только ручное - с 11 появилось автоматическое)... а тут и бэкапы и восстановление автоматическое... и все все все....

)) Самый опытный Oracle DBA в нашей организации даже автоматическое управление памятью СУБД не доверяет (до 11 версии было только ручное - с 11 появилось автоматическое)... а тут и бэкапы и восстановление автоматическое... и все все все....

Если все правда, то он не нужен будет :)

Ребята, всегда ли оправдано в мастер делать insert, а с реплики select делать?

если коротко то не всегда

реплика может отставать и можно в селекте с неё не увидеть свежего инсерта. Приложение должно быть к такому готово

реплика может отставать и можно в селекте с неё не увидеть свежего инсерта. Приложение должно быть к такому готово

?

Ребята, всегда ли оправдано в мастер делать insert, а с реплики select делать?

Если синхронная то да

Если синхронная то да

Синхронность задается в настройках? Эти базы будут в одном кластере Kubernetes, сеть гигабитная между ними.

Синхронность задается в настройках? Эти базы будут в одном кластере Kubernetes, сеть гигабитная между ними.

Да в настройках постгри. Кубик там или в железе без разницы. Но по скорости просядет

Да в настройках постгри. Кубик там или в железе без разницы. Но по скорости просядет

значительно просядет? лучше внутри виртуалки поднять? для базы отдельного железа нету пока что

значительно просядет? лучше внутри виртуалки поднять? для базы отдельного железа нету пока что

Задай вопрос нужна ли тебе синхронная репликации? Может лучше асинхронная?

значительно просядет? лучше внутри виртуалки поднять? для базы отдельного железа нету пока что

Вот здесь однозначного ответа нет. Тесты и еще раз тесты.

Похоже, надо еще покурить доки)

при remote_write просядет на запись где то в 1,3 раза, remote_apply - 1,5 раза. Но это очень приблизительно, нужно разбираться в вашем профиле нагрузки. Вы можете делать синхронными только определенные транзакции, которые критичны к читающим операциям на реплике. Но это более гибкая и сложная работа.

Если синхронная то да

Тоже не гарантирует консистентности, кстати.

значительно просядет? лучше внутри виртуалки поднять? для базы отдельного железа нету пока что

Раз у Вас вообще есть возможность рассматривать этот вариант, почему сразу не начать с асинхронной?

Тоже не гарантирует консистентности, кстати.

А можно по-подробней, где почитать.

hash индексы?

А можно по-подробней, где почитать.

https://www.postgresql.org/docs/current/static/applevel-consistency.html#SERIALIZABLE-CONSISTENCY Там warning.

https://www.postgresql.org/docs/current/static/applevel-consistency.html#SERIALIZABLE-CONSISTENCY Там warning.

thx

https://www.postgresql.org/docs/current/static/applevel-consistency.html#SERIALIZABLE-CONSISTENCY Там warning.

Он же о другом? Или я не понимаю?

Я и не вижу смысла в serializable на standby

Он же о другом? Или я не понимаю?

Warning This level of integrity protection using Serializable transactions does not yet extend to hot standby mode. Т.е. hot standby ACID consistency (и isolation) _не обеспечивает_.

Я и не вижу смысла в serializable на standby

Почему это, интересно?

Там записи нет. Все выборки при операции записи (процесс восстановления) завершаются - то есть не могут вернуть неконсистентный набор данных

Там записи нет. Все выборки при операции записи (процесс восстановления) завершаются - то есть не могут вернуть неконсистентный набор данных

Могут. Warning там не просто так. То, что выборка возращает какой-то snapshot, не значит, что он относится к какому-то _консистентному состоянию_ master-а, вот в чём штука...

значительно просядет? лучше внутри виртуалки поднять? для базы отдельного железа нету пока что

Предположу , что "просядет" было про включение синхронной репликации

То есть - если мы используем на мастере - иные уровни изоляции - то снапшот на standby может быть неконсистентен. Так правильно читается этот ворнинг?

То есть - если мы используем на мастере - иные уровни изоляции - то снапшот на standby может быть неконсистентен. Так правильно читается этот ворнинг?

Какие "иные"? Если мы даже используем SERIALIZABLE на master-е, на slave всё равно можно наблюдать неконсистентные состояния.

Какие "иные"? Если мы даже используем SERIALIZABLE на master-е, на slave всё равно можно наблюдать неконсистентные состояния.

Вот это да - непонятно. Видимо надо углубляться в реализацию записи wal и особенности их применения на мастере в режиме serializable... Вы подробностей такого поведения не знаете?

Вот это да - непонятно. Видимо надо углубляться в реализацию записи wal и особенности их применения на мастере в режиме serializable... Вы подробностей такого поведения не знаете?

Это (реализацию записи wal и особенности их применения на мастере) здесь ни при чём. Дело в том, что predicate locking на slave не выполняется (и никаких других механизмов, вроде передачи safe snapshots с master, сейчас нет). Поэтому slave позволяет "увидеть" (читать) snapshot-ы, при попытке чтения которых на master Вы бы получили serialization failure.

Поищу материал. Стало интересно

Вот, кажется, последний thread в -hackers по этому поводу: https://www.postgresql.org/message-id/CAEepm%3D2b9TV%2BvJ4UeSBixDrW7VUiTjxPwWq8K3QwFSWx0pTXHQ%40mail.gmail.com

и правда интересно

Это (реализацию записи wal и особенности их применения на мастере) здесь ни при чём. Дело в том, что predicate locking на slave не выполняется (и никаких других механизмов, вроде передачи safe snapshots с master, сейчас нет). Поэтому slave позволяет "увидеть" (читать) snapshot-ы, при попытке чтения которых на master Вы бы получили serialization failure.

Есть где нибудь описание всех этих serializable и проч изоляций для бедных умом? Я официальную доку и читал, слова понимаю, но интуитивно о чем они в целом все равно понять не могу.

Есть где нибудь описание всех этих serializable и проч изоляций для бедных умом? Я официальную доку и читал, слова понимаю, но интуитивно о чем они в целом все равно понять не могу.

А это https://wiki.postgresql.org/wiki/Serializable и это http://wiki.postgresql.org/wiki/SSI видели? Вообще это нетривиальная штука, вот в чём дело. Даже сам алгоритм был создан только в 2008 году, кажется.

Есть где нибудь описание всех этих serializable и проч изоляций для бедных умом? Я официальную доку и читал, слова понимаю, но интуитивно о чем они в целом все равно понять не могу.

Зато, с другой стороны, для использования SERIALIZABLE знать всё это совсем не нужно —- просто соблюдайте простые правила, и всё: Consistent use of Serializable transactions can simplify development. The guarantee that any set of successfully committed concurrent Serializable transactions will have the same effect as if they were run one at a time means that if you can demonstrate that a single transaction, as written, will do the right thing when run by itself, you can have confidence that it will do the right thing in any mix of Serializable transactions, even without any information about what those other transactions might do, or it will not successfully commit. It is important that an environment which uses this technique have a generalized way of handling serialization failures (which always return with a SQLSTATE value of '40001'), because it will be very hard to predict exactly which transactions might contribute to the read/write dependencies and need to be rolled back to prevent serialization anomalies. К тому же, в любом правильно написанном приложении такой обработчик исключений уже есть (хотя бы для DEADLOCK-ов), расширить его (добавить SQLSTATE 40001) должно быть тривиально.

Тут существенно улучшить конечно не получится. Думаю под конкретно этот запрос строить индекс типа create index on countrylanguage (language , countrycode) ; (аналог первичного ключа в этой таблице) безсмысленно. Но вот немного странно, что у меня план дает 1 секунду время выполнения у вас аж 4.... на таких объемах размер ram не играет значения. Интересно на чем вы выполняете запросы.

утра. я так понимаю, мой вчерашний вопрос закрыт?

утра. я так понимаю, мой вчерашний вопрос закрыт?

У меня остаются вопросы к 4м секундам... Чет долго )

я согласен получить сравнение с мыскулем на том же железе

ну и там не 4 сек, а в реальности где то 2.5 мсек

Мыскуль какой версии?

5.7.21

У меня остаются вопросы к 4м секундам... Чет долго )

миллисекундам

миллисекундам

Да. Я там приводил свой план - у меня в 4 раза лучше