Мне конечно по душе больше трамваи. Кажется, что пробка со стороны Новоясеневского по вечерам осталась. Во-первых, те, кто разворачивается с запада на восток конфликтуют с автобусами, выезжающими из парка. Во-вторых полноценная выделенка с камерами вроде бы должна минимизировать влияние на автобусы, но они пытаются объезжать друг друга, потому что у кого-то на ней долгая посадка, а кому-то надо быстро проехать. Если смотреть на пробку с юга Профсоюзной, то она вроде из-за гигантского потока поворачивающих на Новоясеневский и разворачивающихся в область, но те и другие ждут/уступают.
Да - на НЧ, нет - на СЧ/ВЧ. Частично да - во всём диапазоне. Дифракционная картина на НЧ довольно устойчива при отклонениях слушателя в пространстве и крайне неустойчива на ВЧ (для малых длин волн), поэтому на ВЧ точная коррекция невозможна в точке прослушивания. По всему диапазону снять и скорректировать в точке прослушивания можно/нужно, но с сильным сглаживанием. С многополосными колонками нужно, если диаграмма направленности сильно различается между полосами. Например, если на ВЧ излучатель Хейла, а на СЧ/НЧ обычные динамики. От вида диаграммы направленности очень зависит затухание сигнала с расстоянием, для Хейла затухание существенно слабее.
Спасибо за статью, следил за развитием transparent alter table и тут такое... Подскажите, можно ли использовать для перевода из одной схемы партицирования в другую? Как и в tat, таблица для захвата изменений сделана unlogged: это безопасно? Ещё такое предложение помимо опционального analyze сделать опциональный vacuum, чтобы проставить hint bits.
Вообще оценить число строк при join очень непросто, а знание, что есть связь по FK, сильно упрощает. Если две таблицы связаны по FK, то кардинальность пересечения множеств известна заранее. Проверил, похоже в postgres нет этой оптимизации.
В этом примере что-то недосказанно. На производительность чтения FK плохо не влияет, но позволяет точнее оценить количество строк при join по FK. На скорость изменений данных влияет, но только если менять значения столбцов FK или PK/UK. Есть случаи, когда блокировки в БД должны сильно распространиться по связанным по FK таблицам, но этот эффект можно минимизировать.
В той системе запросы написаны руками или ORM? Вы просто пишете, что ORM следит за консистентностью при каскадных операциях, но если не принять нужных мер (индексы для FK), то и ORM тоже начнёт тормозить.
Как на счёт TT-shape? Когда, например, инженер-электронщик (T) умеет в профессию в IT (T). С точки зрения работодателя совершенно бесполезная половина сотрудника ведь?
Понимаю Ваше страдание, я переписывал руками, заодно оптимизировал кучу запросов и понял, что в mssql оптимизатор просто конфетка по отношению к самым ужасным запросам, которые без переписывания работают очень плохо в postgres.
По п. 1, 2, 4 правильно. В 3 тоже, но надо добавить, что активное подключение сохраняется для повторного использования до конца сессии (keep_connections). Сравнение не проведу, мало использовал dblink. Но postgres_fdw точно надёжный даже в высоконагруженных базах, и он продолжает развиваться.
Это рабочий вариант в postgresql. Достаточно таблицу источника подключить к БД приёмника (не наоборот) через FDW. И это один из самых эффективных способов. К тому же, на нём можно сделать захват изменений и не потерять тех данных, что сделали в источнике во время копирования.
Однажды, в силу определенных причин, было принято решение архитектурно перейти с PostgreSQL на распределенную систему управления базами данных CockroachDB.
Из графика можно сделать вывод, что Pyomo с солвером ipopt значительно превосходит SciPy с cobyla при N > 20.
По-моему не очень корректное сравнение: ipopt использует 1 и 2 производные (градиент и гессиан), а cobyla - нет. Последний подходит и для случая, когда производные невычислимы. В первом явное определение производных должно сильно ускорить.
Кстати, а эта задача не имеет ли аналитического решения? Или её можно свести к СНАУ?
Такие организации есть. Хотя в большинстве случаев в них нет BYOD, а на свой ноутбук работодатель может что угодно поставить. Росбанк - первый, у которого я вижу BYOD и хочется получить комментарий про обязанное применение DLP на конечном устройстве.
Include - очень крутая штука, возникшая благодаря вашей компании. Вполне вероятно, она может стать в перспективе IOT, хотя при нынешнем устройстве Postgres это маловероятно. Очень серьезное препятствие вижу в самой оценке, когда возможен index only scan и зачастую оптимизатор его отвергает из-за visibility map. В противовес include другой подход с узким уникальным индексом для ключа не требует index only scan и выглядит выигрышно при интенсивных update за счёт HOT, если вообще не обновлять столбцы в индексах.
Что про bitmap scan, то он выглядит быстрее, чем index scan, если recheck после сканирования не фильтрует много строк. Наблюдал, что bitmap scan чаще бывает, если в pg_stats хорошая correlation у столбца, по которому запрашивается поиск по диапазону. Кроме столбцов, которые сами растут со временем (sequence, now), это можно сделать, если заранее выполнить cluster. Есть тут подвох, что для tuple из 2 столбцов(напр., client_id, create_time) оценка correlation не выполняется и запрос с условием client_id=<constant> and create_time between... не будет использовать bitmap scan даже если заранее сделать cluster по индексу из этих двух столбцов. Хотя тут это самый эффективный метод.
Мы в ЛиАЗах ещё и прыгали на задней площадке, чтобы усилить ощущения полёта.
Мне конечно по душе больше трамваи.
Кажется, что пробка со стороны Новоясеневского по вечерам осталась. Во-первых, те, кто разворачивается с запада на восток конфликтуют с автобусами, выезжающими из парка. Во-вторых полноценная выделенка с камерами вроде бы должна минимизировать влияние на автобусы, но они пытаются объезжать друг друга, потому что у кого-то на ней долгая посадка, а кому-то надо быстро проехать.
Если смотреть на пробку с юга Профсоюзной, то она вроде из-за гигантского потока поворачивающих на Новоясеневский и разворачивающихся в область, но те и другие ждут/уступают.
Да - на НЧ, нет - на СЧ/ВЧ. Частично да - во всём диапазоне.
Дифракционная картина на НЧ довольно устойчива при отклонениях слушателя в пространстве и крайне неустойчива на ВЧ (для малых длин волн), поэтому на ВЧ точная коррекция невозможна в точке прослушивания.
По всему диапазону снять и скорректировать в точке прослушивания можно/нужно, но с сильным сглаживанием. С многополосными колонками нужно, если диаграмма направленности сильно различается между полосами. Например, если на ВЧ излучатель Хейла, а на СЧ/НЧ обычные динамики. От вида диаграммы направленности очень зависит затухание сигнала с расстоянием, для Хейла затухание существенно слабее.
Спасибо за статью, следил за развитием transparent alter table и тут такое... Подскажите, можно ли использовать для перевода из одной схемы партицирования в другую? Как и в tat, таблица для захвата изменений сделана unlogged: это безопасно? Ещё такое предложение помимо опционального analyze сделать опциональный vacuum, чтобы проставить hint bits.
Вообще оценить число строк при join очень непросто, а знание, что есть связь по FK, сильно упрощает. Если две таблицы связаны по FK, то кардинальность пересечения множеств известна заранее. Проверил, похоже в postgres нет этой оптимизации.
В этом примере что-то недосказанно. На производительность чтения FK плохо не влияет, но позволяет точнее оценить количество строк при join по FK. На скорость изменений данных влияет, но только если менять значения столбцов FK или PK/UK. Есть случаи, когда блокировки в БД должны сильно распространиться по связанным по FK таблицам, но этот эффект можно минимизировать.
В той системе запросы написаны руками или ORM? Вы просто пишете, что ORM следит за консистентностью при каскадных операциях, но если не принять нужных мер (индексы для FK), то и ORM тоже начнёт тормозить.
Как на счёт TT-shape? Когда, например, инженер-электронщик (T) умеет в профессию в IT (T). С точки зрения работодателя совершенно бесполезная половина сотрудника ведь?
Круто ведь, тут Distributed DBMS, а в System I разве так?
Понимаю Ваше страдание, я переписывал руками, заодно оптимизировал кучу запросов и понял, что в mssql оптимизатор просто конфетка по отношению к самым ужасным запросам, которые без переписывания работают очень плохо в postgres.
Не использовали tds_fdw?
Силами самой СУБД postgres: pg_upgrade с параметром -k, будет небольшой перерыв, конечно.
По п. 1, 2, 4 правильно. В 3 тоже, но надо добавить, что активное подключение сохраняется для повторного использования до конца сессии (keep_connections). Сравнение не проведу, мало использовал dblink. Но postgres_fdw точно надёжный даже в высоконагруженных базах, и он продолжает развиваться.
Это рабочий вариант в postgresql. Достаточно таблицу источника подключить к БД приёмника (не наоборот) через FDW. И это один из самых эффективных способов. К тому же, на нём можно сделать захват изменений и не потерять тех данных, что сделали в источнике во время копирования.
Какие были причины?
По-моему не очень корректное сравнение: ipopt использует 1 и 2 производные (градиент и гессиан), а cobyla - нет. Последний подходит и для случая, когда производные невычислимы. В первом явное определение производных должно сильно ускорить.
Кстати, а эта задача не имеет ли аналитического решения? Или её можно свести к СНАУ?
О, теперь я понял, почему очередная "служба безопасности сбербанка" назвала меня по имени из профиля WB
Спасибо за статью. Тоже обнаружил, что BRIN ломает HOT. Вы не проводили проверку, это сложно исправить?
Такие организации есть. Хотя в большинстве случаев в них нет BYOD, а на свой ноутбук работодатель может что угодно поставить. Росбанк - первый, у которого я вижу BYOD и хочется получить комментарий про обязанное применение DLP на конечном устройстве.
Include - очень крутая штука, возникшая благодаря вашей компании. Вполне вероятно, она может стать в перспективе IOT, хотя при нынешнем устройстве Postgres это маловероятно. Очень серьезное препятствие вижу в самой оценке, когда возможен index only scan и зачастую оптимизатор его отвергает из-за visibility map. В противовес include другой подход с узким уникальным индексом для ключа не требует index only scan и выглядит выигрышно при интенсивных update за счёт HOT, если вообще не обновлять столбцы в индексах.
Что про bitmap scan, то он выглядит быстрее, чем index scan, если recheck после сканирования не фильтрует много строк. Наблюдал, что bitmap scan чаще бывает, если в pg_stats хорошая correlation у столбца, по которому запрашивается поиск по диапазону. Кроме столбцов, которые сами растут со временем (sequence, now), это можно сделать, если заранее выполнить cluster. Есть тут подвох, что для tuple из 2 столбцов(напр., client_id, create_time) оценка correlation не выполняется и запрос с условием client_id=<constant> and create_time between... не будет использовать bitmap scan даже если заранее сделать cluster по индексу из этих двух столбцов. Хотя тут это самый эффективный метод.