Size: a a a

pgsql – PostgreSQL

2021 February 28

AT

Andrey Tatarnikov in pgsql – PostgreSQL
В крайний раз на склонированной таблице, на которой ещё не было индексов совсем, примерно похожее упражнение заняло минут 40 чистого времени на update. На сколько оно просядет если запустить update на таблице как есть, с индексами, читателями и писателями - даже не знаю как прикинуть
источник

AT

Andrey Tatarnikov in pgsql – PostgreSQL
Yaroslav Schekin
А тестового сервера нет? Если есть — можно было бы узнать хоть примерно.
На стендах ресурсов меньше, там только логика тестируется сейчас. Можно было бы подумать и собрать аналогичный по ресурсам стенд, но нагрузку взять негде все равно. Или писать отдельно роботов, чтобы нагрузку имитировали
источник

кн

коля николай... in pgsql – PostgreSQL
еще один вопрос, вам точно нужно перезаписывать это поле? Если вы часто это делаете может имеет смысл его хранить отдельно?
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Andrey Tatarnikov
В крайний раз на склонированной таблице, на которой ещё не было индексов совсем, примерно похожее упражнение заняло минут 40 чистого времени на update. На сколько оно просядет если запустить update на таблице как есть, с индексами, читателями и писателями - даже не знаю как прикинуть
Как-то ну очень долго. А вообще, если уж воспроизводить, то как можно ближе к реальности.
Но уж заморачиваться с имитацией нагрузки только ради этого я бы не стал.
источник

AT

Andrey Tatarnikov in pgsql – PostgreSQL
коля николай
еще один вопрос, вам точно нужно перезаписывать это поле? Если вы часто это делаете может имеет смысл его хранить отдельно?
С этим полем такое впервые. :) Вообще задача возникает раз в пару лет, примерно, когда что-то сдвигается в бизнес требованиях и нужно делать начальную загрузку данных, просчитанных по новым правилам
источник

AT

Andrey Tatarnikov in pgsql – PostgreSQL
Yaroslav Schekin
Как-то ну очень долго. А вообще, если уж воспроизводить, то как можно ближе к реальности.
Но уж заморачиваться с имитацией нагрузки только ради этого я бы не стал.
Это интересное замечание. А очень долго в принципе или с учётом постоянно присутствующей нагрузки и ещё полсотни таблиц - может быть и нормально?
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Andrey Tatarnikov
Это интересное замечание. А очень долго в принципе или с учётом постоянно присутствующей нагрузки и ещё полсотни таблиц - может быть и нормально?
Если интенсивная нагрузка — может быть, и нормально, конечно.
источник

AT

Andrey Tatarnikov in pgsql – PostgreSQL
Львиная доля нагрузки по сути - olap. Постоянно приходят пачки запросов с пачками джоинов, убийственными условиями, перекладыванием промежуточных результатов в unlogged таблицы и вот этим всем
источник

кн

коля николай... in pgsql – PostgreSQL
мне кажется самое быстрое будет создать таблицу и нагнать туда данные из старой таблицы ( сразу подменяя нужное значение) потом строить индексы и переключаться.
источник

кн

коля николай... in pgsql – PostgreSQL
коля николай
мне кажется самое быстрое будет создать таблицу и нагнать туда данные из старой таблицы ( сразу подменяя нужное значение) потом строить индексы и переключаться.
главное уйти от апдейтов
источник

AT

Andrey Tatarnikov in pgsql – PostgreSQL
О. Так не пробовал ещё :)
источник

кн

коля николай... in pgsql – PostgreSQL
Andrey Tatarnikov
О. Так не пробовал ещё :)
отпиши потом насколько ускорило)
источник

DP

Darafei Praliaskousk... in pgsql – PostgreSQL
можно вьюху собрать из новой таблицы и вьюхи на старую+патч
источник

DP

Darafei Praliaskousk... in pgsql – PostgreSQL
если запись тебе подконтрольна и не размазана по всему приложению, то после этого можно сколько угодно времени переливать из старой таблицы в новую построчно накладывая патч
источник

DP

Darafei Praliaskousk... in pgsql – PostgreSQL
insert from delete returning :)
источник

AT

Andrey Tatarnikov in pgsql – PostgreSQL
Не вариант. Рано или поздно окно maintenance надо заканчивать, а тогда включится интеграция с dwh системами и начнет приносить апдейты строк, включая это поле :)
источник

VY

Victor Yegorov in pgsql – PostgreSQL
Andrey Tatarnikov
Операции, которые набегут, я и так достану, это не сложно - там очень ограниченный объем того, что может в теории набежать. Было больше интересно как люди подобное решают. Батчи исторически не рассматривались, потому что долго и много накладных расходов. Апдейт всем куском ни разу не пробовали, может он за несколько часов и пролез бы, а может и нет
каждый день порочёсываем таблицу на 450GB целиком, в 12 потоков, батчами по 1000 страниц. примерно 4 часа
источник

DP

Darafei Praliaskousk... in pgsql – PostgreSQL
Andrey Tatarnikov
Не вариант. Рано или поздно окно maintenance надо заканчивать, а тогда включится интеграция с dwh системами и начнет приносить апдейты строк, включая это поле :)
что даёт уникальную возможность погрузиться в рулы :)
https://www.postgresql.org/docs/13/sql-createrule.html
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Вместе с "уникальной" возможностью запороть свои данные. ;(
https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_rules
источник

AT

Andrey Tatarnikov in pgsql – PostgreSQL
Яснопонятно :) сдается мне, чем больше я советуюсь с сообществом по своим задачам, тем больше возникает аргументов за переезд из SaaS в on premise
источник