YS
тогда почему у меня были проигнорированы все условия и 400 млн записей легли в 1 таблицу, а не распределились? Я сейчас проверил работают ли условия на обычный инсерт - работают
А кто его знает — покажите версию PostgreSQL и \d+ таблицы.
Size: a a a
2020 June 30
👨n
Yaroslav Schekin
А кто его знает — покажите версию PostgreSQL и \d+ таблицы.
Версия 11.7
👨n
правила такого вида
👨n
и заливаю через стриминг
DE
но когда в эту схему завожу pgbouncer, то непонятно что делать, если он упал
оперативно поднимать
s0
а если я патрони через баунсер пущу?
А
Yaroslav Schekin
А почему не так, как Вы написали (хотя это и подозрительно смахивает на EAV... но кто его знает, какие там "свойства")?
это скорее и есть EAV. Свойства могут быть string, int, bool, Class. Именно с классом вот проблема, потому что классы могут юзаться и в остальных классах
YS
Правила, my eye. ;(
Не используйте rules никогда! См. https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_rules
Т.е. "сами виноваты". Стоит переделать это всё на native (или, на худой конец, trigger) partitioning.
Не используйте rules никогда! См. https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_rules
Т.е. "сами виноваты". Стоит переделать это всё на native (или, на худой конец, trigger) partitioning.
👨n
Yaroslav Schekin
Правила, my eye. ;(
Не используйте rules никогда! См. https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_rules
Т.е. "сами виноваты". Стоит переделать это всё на native (или, на худой конец, trigger) partitioning.
Не используйте rules никогда! См. https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_rules
Т.е. "сами виноваты". Стоит переделать это всё на native (или, на худой конец, trigger) partitioning.
в смысле на нейтив?
👨n
а тригеры же срабатывают после добавления записи в базу, разве нет?
👨n
т.е. запись залетает в таблицу куда не следует и... что?
А
Yaroslav Schekin
А почему не так, как Вы написали (хотя это и подозрительно смахивает на EAV... но кто его знает, какие там "свойства")?
попробовал вариант EAV не понравился, перешел в JSONB но там эта же проблема. в общем было б интересно послушать мнения со стороны
YS
в смысле на нейтив?
В прямом. https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITIONING-DECLARATIVE
Кстати, даже в документации COPY написано: "COPY FROM will invoke any triggers and check constraints on the destination table. However, it will not invoke rules."
Кстати, даже в документации COPY написано: "COPY FROM will invoke any triggers and check constraints on the destination table. However, it will not invoke rules."
YS
а тригеры же срабатывают после добавления записи в базу, разве нет?
Хмм... а Вы вообще читали документацию про partitioning? ;)
Там же это "разжёвано", с примерами.
Там же это "разжёвано", с примерами.
👨n
Yaroslav Schekin
Хмм... а Вы вообще читали документацию про partitioning? ;)
Там же это "разжёвано", с примерами.
Там же это "разжёвано", с примерами.
от корочки до корочки - нет, по этому использовал то что сделал другой чел)
👨n
и вот на
copy споткнулся когда база нагнулась внезапноYS
это скорее и есть EAV. Свойства могут быть string, int, bool, Class. Именно с классом вот проблема, потому что классы могут юзаться и в остальных классах
Так раз это EAV — Вы обречены страдать (я не шучу).
Это нереляционная "модель", использование её в RDBMS почти всегда приводит к "ягодкам" потом.
Потому это и antipattern. :(
Это нереляционная "модель", использование её в RDBMS почти всегда приводит к "ягодкам" потом.
Потому это и antipattern. :(
👨n
Yaroslav Schekin
В прямом. https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITIONING-DECLARATIVE
Кстати, даже в документации COPY написано: "COPY FROM will invoke any triggers and check constraints on the destination table. However, it will not invoke rules."
Кстати, даже в документации COPY написано: "COPY FROM will invoke any triggers and check constraints on the destination table. However, it will not invoke rules."
т.е. я партиции создавал по шаблону
Мне выходит надо их скорректировать или по новой создавать?
CREATE TABLE transactions_eth_earliest (
CHECK ( currency = 'eth' and date < '2017-01-01' )
) INHERITS (transactions_v2);
Мне выходит надо их скорректировать или по новой создавать?
YS
т.е. я партиции создавал по шаблону
Мне выходит надо их скорректировать или по новой создавать?
CREATE TABLE transactions_eth_earliest (
CHECK ( currency = 'eth' and date < '2017-01-01' )
) INHERITS (transactions_v2);
Мне выходит надо их скорректировать или по новой создавать?
Да, Вам нужно выкинуть всю эту ерунду, и использовать declarative partitioning (к счастью, с ним и работать гораздо проще, поэтому получиться должно быстрее... но данные, если есть, придётся перелить).
Вообще говоря, это основной метод партиционирования в PostgreSQL, стоит переходить на него (он уже даёт в сумме больше возможностей, чем другие; и именно его будут развивать дальше).
А уж все rules (кроме ON SELECT = view) давно пора бы выкинуть, IMNSHO. ;)
Вообще говоря, это основной метод партиционирования в PostgreSQL, стоит переходить на него (он уже даёт в сумме больше возможностей, чем другие; и именно его будут развивать дальше).
А уж все rules (кроме ON SELECT = view) давно пора бы выкинуть, IMNSHO. ;)
👨n
Yaroslav Schekin
Да, Вам нужно выкинуть всю эту ерунду, и использовать declarative partitioning (к счастью, с ним и работать гораздо проще, поэтому получиться должно быстрее... но данные, если есть, придётся перелить).
Вообще говоря, это основной метод партиционирования в PostgreSQL, стоит переходить на него (он уже даёт в сумме больше возможностей, чем другие; и именно его будут развивать дальше).
А уж все rules (кроме ON SELECT = view) давно пора бы выкинуть, IMNSHO. ;)
Вообще говоря, это основной метод партиционирования в PostgreSQL, стоит переходить на него (он уже даёт в сумме больше возможностей, чем другие; и именно его будут развивать дальше).
А уж все rules (кроме ON SELECT = view) давно пора бы выкинуть, IMNSHO. ;)
ну у меня там по 5-20 млн строк и вот куда не надо 400 млн свалилось