Особенности работы с temp-таблицами плюс различие в кардинальности значений полей.
В целом это иллюстрация того, что индекс по нескольким полям при условии того, что в качестве первого поля выбирается поле с наибольшим количеством различных вариантов значений, а в качестве последнего поля - с наименьшим количеством различных вариантов значений, предпочтительнее в плане быстродействия при прочих равных.
А также того, что от использования TEMP-таблиц при прочих равных лучше отказываться.
А также того, что автору хочется, чтобы до решения проблемы все доходили одним ему нужным путём, "необходимым и достаточным", а не пытались в установку более адекватного shared_buffers, включение set track_io_timing = on, выполнение ANALYZE (BUFFERS) или избавление от TEMP в CREATE TABLE , а то ещё увидят, что время в основном тратится на чтение с диска, что на "обычной" (не временной) таблице различие менее радикальное за счёт использования shared buffers, а то и вообще придут к тем же выводам насчёт кардинальности/селективности полей другим путём. =)
Формат постов в основе своей - всецело поддерживаю. Ограничение вариантов решения одним правильным - порицаю.
С параметром `listen_addresses` в `postgresql.conf` в статье серьёзная проблема.
Он служит не для задания списка IP-адресов или диапазонов, с которых будут происходить подключения, а для указания списка IP-адресов имеющихся на хосте сетевых интерфейсов, на которых экземпляр postgres должен ожидать ("слушать") и принимать подключения.
С технической стороны всё хорошо, кроме пары моментов:
PostgreSQL выставлять в интернет "голой жопой" не рекомендуется, особенно если пароль на учётку в нём выбран по принципу "что-нибудь простое, например, 123". Довольно быстро такое приводит к тому, что контейнер начинает майнить, либо данные в таблицах оказываются удалены или зашифрованы.
Коль уж поднимаете PostgreSQL в контейнере без вольюма, желательно упомянуть о том, что время жизни БД в этом случае - до смерти контейнера.
В картинке "В каких распространённых СУБД используется" не хватает пояснений, что под этим использованием подразумевается.
В частности, в PostgreSQL "Read Uncomitted" и "Repeatable Read", обозначенные вами минусом, вполне себе реализованы и могут быть использованы. Стандарт SQL не требует, чтобы аномалии, характерные для какого-то из уровней изоляции, обязательно присутствовали; он требует отсутствия характерных аномалий. Другими словами, отсутствие того же самого Dirty Read на Read Uncomitted в PostgreSQL допустимо стандартом SQL: стандарт не обязывает, чтобы Dirty Read был реализован в Read Uncomitted; он обязывает, чтобы Dirty Read отсутствовал в Read Comitted.
Так что я бы на вашем месте добавил пояснение по тому, что означают плюсики и минусики, а то может сложиться впечатление, что речь идёт о том, что эти уровни в PostgreSQL не реализованы или реализованы неправильно, а это не так.
К слову, там ещё при копировании текста со страницы в буфер обмена лишний хлам попадает, прямо как в добрые двухтысячные.
Вроде и нужный функционал (хотя, конечно, сказать, что в Postgres есть только лог и pg_stat_statements - это довольно таки сильно упростить его возможности, но в целом проблема отсутствия событийной трассировки действительно имеет место быть), и, смею надеяться, неплохая реализация, но в то же время по факту вышла узкоспециализированная пропиетарщина непонятной стоимости, защищённая неким аппаратным ключом, предлагаемая к приобретению на сайте с артефактами из прошлого десятилетия. Впрочем, не мне учить людей делать бизнес, я лишь поделился неоднозначными впечатлениями, которых, скажем, при знакомстве с https://pganalyze.com было меньше (цена, хоть и скорее относящаяся к категории "кусающаяся", объявлена; ставить некий программный ключ, не несущий никакой полезной нагрузки и, я уверен, как и любая защита, создающий головняк в самый неподходящий момент, не требуется; сайт сделан нормально и без закидонов; тоже пропиетарщина, которую тем не менее можно поставить после регистрации, а не "мы с вами свяжемся").
Вообще если эти ваши госы мигрируют на версию ОС, в которой максимально возможная совместимая версия СУБД уже EOL, то они, мягко говоря, делают что-то не так.
Попробовал повторить ваш пример создания кластера. Кнопка "Создать" неактивна. Почему неактивна - нигде не написано. Это баг? Это ограничения бета-версии? Недоработка пользовательского интерфейса? Или связано с тем, что где-то в среди прочих элементов управления я ничего не производил с пунктом "Настройка сети" (хотя мне сеть как-раз таки и не нужна, посмотреть я хотел только на облачную СУБД)?
Ну насчёт "каждую парочку" всё же не совсем верно: в некоторых не самых населённых регах (например, в Immensia) целые консты могут на одном сервере находиться. Плюс к тому они явно порой их перераспределяют, вряд ли полностью автоматически. Порой флоты примерно схожих размеров ловят лагалово в том же месте, но просто неделю спустя.
мой бумажник поддерживает суммы в более чем 200000 рублей, но там почему-то меньше.
провод у розетки слева держит до 5 А, но воткнута туда зарядка для телефона.
Где-то в тех же числах перестал работать из России ntp2.kangran.su, до этого работавший десятки лет. И не работает до сих пор.
значит, показалось, сорри. =)
Особенности работы с temp-таблицами плюс различие в кардинальности значений полей.
В целом это иллюстрация того, что индекс по нескольким полям при условии того, что в качестве первого поля выбирается поле с наибольшим количеством различных вариантов значений, а в качестве последнего поля - с наименьшим количеством различных вариантов значений, предпочтительнее в плане быстродействия при прочих равных.
А также того, что от использования TEMP-таблиц при прочих равных лучше отказываться.
А также того, что автору хочется, чтобы до решения проблемы все доходили одним ему нужным путём, "необходимым и достаточным", а не пытались в установку более адекватного
shared_buffers, включениеset track_io_timing = on, выполнениеANALYZE (BUFFERS)или избавление отTEMPвCREATE TABLE, а то ещё увидят, что время в основном тратится на чтение с диска, что на "обычной" (не временной) таблице различие менее радикальное за счёт использования shared buffers, а то и вообще придут к тем же выводам насчёт кардинальности/селективности полей другим путём. =)Формат постов в основе своей - всецело поддерживаю. Ограничение вариантов решения одним правильным - порицаю.
Вы, конечно, извините, но мат и ругань в статьях - это отвратительно.
С параметром `listen_addresses` в `postgresql.conf` в статье серьёзная проблема.
Он служит не для задания списка IP-адресов или диапазонов, с которых будут происходить подключения, а для указания списка IP-адресов имеющихся на хосте сетевых интерфейсов, на которых экземпляр postgres должен ожидать ("слушать") и принимать подключения.
ваш номер в очереди - двадцать третий.
Ну не скажите. Подобная автоматизация развёртывания есть у Виталия Кухарика: https://github.com/vitabaks/postgresql_cluster
С технической стороны всё хорошо, кроме пары моментов:
PostgreSQL выставлять в интернет "голой жопой" не рекомендуется, особенно если пароль на учётку в нём выбран по принципу "что-нибудь простое, например, 123". Довольно быстро такое приводит к тому, что контейнер начинает майнить, либо данные в таблицах оказываются удалены или зашифрованы.
Коль уж поднимаете PostgreSQL в контейнере без вольюма, желательно упомянуть о том, что время жизни БД в этом случае - до смерти контейнера.
Сбер, у вас серт протух.
В законе "О защите прав потребителей" под потребителем имеется ввиду физическое лицо. Как следствие, "без проблем" будет только для физических лиц.
В картинке "В каких распространённых СУБД используется" не хватает пояснений, что под этим использованием подразумевается.
В частности, в PostgreSQL "Read Uncomitted" и "Repeatable Read", обозначенные вами минусом, вполне себе реализованы и могут быть использованы. Стандарт SQL не требует, чтобы аномалии, характерные для какого-то из уровней изоляции, обязательно присутствовали; он требует отсутствия характерных аномалий. Другими словами, отсутствие того же самого Dirty Read на Read Uncomitted в PostgreSQL допустимо стандартом SQL: стандарт не обязывает, чтобы Dirty Read был реализован в Read Uncomitted; он обязывает, чтобы Dirty Read отсутствовал в Read Comitted.
Так что я бы на вашем месте добавил пояснение по тому, что означают плюсики и минусики, а то может сложиться впечатление, что речь идёт о том, что эти уровни в PostgreSQL не реализованы или реализованы неправильно, а это не так.
К слову, там ещё при копировании текста со страницы в буфер обмена лишний хлам попадает, прямо как в добрые двухтысячные.
Вроде и нужный функционал (хотя, конечно, сказать, что в Postgres есть только лог и pg_stat_statements - это довольно таки сильно упростить его возможности, но в целом проблема отсутствия событийной трассировки действительно имеет место быть), и, смею надеяться, неплохая реализация, но в то же время по факту вышла узкоспециализированная пропиетарщина непонятной стоимости, защищённая неким аппаратным ключом, предлагаемая к приобретению на сайте с артефактами из прошлого десятилетия. Впрочем, не мне учить людей делать бизнес, я лишь поделился неоднозначными впечатлениями, которых, скажем, при знакомстве с https://pganalyze.com было меньше (цена, хоть и скорее относящаяся к категории "кусающаяся", объявлена; ставить некий программный ключ, не несущий никакой полезной нагрузки и, я уверен, как и любая защита, создающий головняк в самый неподходящий момент, не требуется; сайт сделан нормально и без закидонов; тоже пропиетарщина, которую тем не менее можно поставить после регистрации, а не "мы с вами свяжемся").
Вообще если эти ваши госы мигрируют на версию ОС, в которой максимально возможная совместимая версия СУБД уже EOL, то они, мягко говоря, делают что-то не так.
Попробовал повторить ваш пример создания кластера. Кнопка "Создать" неактивна. Почему неактивна - нигде не написано. Это баг? Это ограничения бета-версии? Недоработка пользовательского интерфейса? Или связано с тем, что где-то в среди прочих элементов управления я ничего не производил с пунктом "Настройка сети" (хотя мне сеть как-раз таки и не нужна, посмотреть я хотел только на облачную СУБД)?
Ну насчёт "каждую парочку" всё же не совсем верно: в некоторых не самых населённых регах (например, в Immensia) целые консты могут на одном сервере находиться. Плюс к тому они явно порой их перераспределяют, вряд ли полностью автоматически. Порой флоты примерно схожих размеров ловят лагалово в том же месте, но просто неделю спустя.
То что надо, спасибо.
провод у розетки слева держит до 5 А, но воткнута туда зарядка для телефона.