<
ребят, может кто подсказать, что необходимо записать в issue_description?
Size: a a a
2021 February 17
<
YS
<
Yaroslav Schekin
Необходимо написать это в какой-то другой чат. ;)
Ну MySQL же...
Ну MySQL же...
да, я думаю от psql не сильно будет отличатся
KT
Добрый день, скажите, какие есть инструменты по партиционированию таблиц?
У меня есть база с набором таблиц. Мне нужно партиционировать некоторые из них. Дело в том, что там есть связи между этими таблицами и руками переписывать их сложно. Все таблицы партиционируются по одному набору значений, поэтому связи можно сохранить между партициями.
Мне кажется, что должен быть уже готовый инструмент для этого.
У меня есть база с набором таблиц. Мне нужно партиционировать некоторые из них. Дело в том, что там есть связи между этими таблицами и руками переписывать их сложно. Все таблицы партиционируются по одному набору значений, поэтому связи можно сохранить между партициями.
Мне кажется, что должен быть уже готовый инструмент для этого.
YS
Добрый день, скажите, какие есть инструменты по партиционированию таблиц?
У меня есть база с набором таблиц. Мне нужно партиционировать некоторые из них. Дело в том, что там есть связи между этими таблицами и руками переписывать их сложно. Все таблицы партиционируются по одному набору значений, поэтому связи можно сохранить между партициями.
Мне кажется, что должен быть уже готовый инструмент для этого.
У меня есть база с набором таблиц. Мне нужно партиционировать некоторые из них. Дело в том, что там есть связи между этими таблицами и руками переписывать их сложно. Все таблицы партиционируются по одному набору значений, поэтому связи можно сохранить между партициями.
Мне кажется, что должен быть уже готовый инструмент для этого.
Посмотрите pg_partman (но я сходу не помню, есть это там или нет).
> там есть связи между этими таблицами и руками переписывать их сложно
А зачем там что-то переписывать руками, кстати?
Связи в партиционированных таблицах должны остаться те же, какие были в исходных (а иначе партиционировать с их сохранением просто не получится).
> там есть связи между этими таблицами и руками переписывать их сложно
А зачем там что-то переписывать руками, кстати?
Связи в партиционированных таблицах должны остаться те же, какие были в исходных (а иначе партиционировать с их сохранением просто не получится).
s
Некоторые "синьоры" отвечают "как ты даже этого не знаешь?"))
И шта? Не знать не стыдно, стыдно не хотеть узнать.
KT
Yaroslav Schekin
Посмотрите pg_partman (но я сходу не помню, есть это там или нет).
> там есть связи между этими таблицами и руками переписывать их сложно
А зачем там что-то переписывать руками, кстати?
Связи в партиционированных таблицах должны остаться те же, какие были в исходных (а иначе партиционировать с их сохранением просто не получится).
> там есть связи между этими таблицами и руками переписывать их сложно
А зачем там что-то переписывать руками, кстати?
Связи в партиционированных таблицах должны остаться те же, какие были в исходных (а иначе партиционировать с их сохранением просто не получится).
Я смотрел на pg_partman, но на сколько я понял он следит за заведением партиций, а не за конвертацией таблицы в партиционированную (может я не там смотрел, подскажете как найти?)
Зачем переписывать:
Покажу на примере двух таблиц. bo и document. document ссылается на bo. Я разбиваю талицу bo например на 3 партиции bo_1, bo_2 и bo_3. Таблицу document я тоже разрезаю на 3 партиции (у меня есть такая возможность: колонка для партиционирования есть в обеих таблицах и у связанных записей значения этой колонки совпадают) document_1, document_2 и document_3.
Так как изначально таблица document ссылалась на bo, то у партиций мы должны восстановить эту связь для ссылочной целостности, т. е. для document_1 нужно сделать ссылку на bo_1 и т. д. Таблиц у меня с десяток, а партиций предполагается около 90. 900 связей руками прописывать тяжко.
Говоря про ссылку я понимаю внешний ключ (т. е. ограничение REFERENCES)
Зачем переписывать:
Покажу на примере двух таблиц. bo и document. document ссылается на bo. Я разбиваю талицу bo например на 3 партиции bo_1, bo_2 и bo_3. Таблицу document я тоже разрезаю на 3 партиции (у меня есть такая возможность: колонка для партиционирования есть в обеих таблицах и у связанных записей значения этой колонки совпадают) document_1, document_2 и document_3.
Так как изначально таблица document ссылалась на bo, то у партиций мы должны восстановить эту связь для ссылочной целостности, т. е. для document_1 нужно сделать ссылку на bo_1 и т. д. Таблиц у меня с десяток, а партиций предполагается около 90. 900 связей руками прописывать тяжко.
Говоря про ссылку я понимаю внешний ключ (т. е. ограничение REFERENCES)
s
Tima
Я пока изучаю бд, и мне дали такое задание. У меня нет объективного взгляда на логику поставленной задачи, так как моих собственных знаний не достаточно, да и нет особого опыта.
Возможно я действительно делаю бессмысленную задачу, но не понимаю этого. Но я не могу не делать, ибо задача поставлена тех . диром и за исключением "эксперты из телеги сказали что это бессмысленно" других аргументов у меня нет. Тем более когда говорят " По молодости когда ток начал учить, я уже делал такое" сложно усомнится в сказанном.
Возможно я действительно делаю бессмысленную задачу, но не понимаю этого. Но я не могу не делать, ибо задача поставлена тех . диром и за исключением "эксперты из телеги сказали что это бессмысленно" других аргументов у меня нет. Тем более когда говорят " По молодости когда ток начал учить, я уже делал такое" сложно усомнится в сказанном.
Я, конечно, припозднился, но фраза "по молодости, когда только начинал учить" это вот вообще хреновая апелляция к осмысленности действия. То, что просили сделать это натурально противоречит здравому смыслу и является плохой можелью данных. Существуют сортировки по порядку, отсортируйте по дате. Хотите какие-то возрастающие id в жсоне? Ну окей, добавляйте в выборку дополнительно фейковые id.
Если техдир неадекватно относится к указаниям на его неправоту и не в состоянии пояснить зачем нужно вручную поддерживать неестественную модель данных вместо использования нормальной, то это мрак.
Если техдир неадекватно относится к указаниям на его неправоту и не в состоянии пояснить зачем нужно вручную поддерживать неестественную модель данных вместо использования нормальной, то это мрак.
YS
Я смотрел на pg_partman, но на сколько я понял он следит за заведением партиций, а не за конвертацией таблицы в партиционированную (может я не там смотрел, подскажете как найти?)
Зачем переписывать:
Покажу на примере двух таблиц. bo и document. document ссылается на bo. Я разбиваю талицу bo например на 3 партиции bo_1, bo_2 и bo_3. Таблицу document я тоже разрезаю на 3 партиции (у меня есть такая возможность: колонка для партиционирования есть в обеих таблицах и у связанных записей значения этой колонки совпадают) document_1, document_2 и document_3.
Так как изначально таблица document ссылалась на bo, то у партиций мы должны восстановить эту связь для ссылочной целостности, т. е. для document_1 нужно сделать ссылку на bo_1 и т. д. Таблиц у меня с десяток, а партиций предполагается около 90. 900 связей руками прописывать тяжко.
Говоря про ссылку я понимаю внешний ключ (т. е. ограничение REFERENCES)
Зачем переписывать:
Покажу на примере двух таблиц. bo и document. document ссылается на bo. Я разбиваю талицу bo например на 3 партиции bo_1, bo_2 и bo_3. Таблицу document я тоже разрезаю на 3 партиции (у меня есть такая возможность: колонка для партиционирования есть в обеих таблицах и у связанных записей значения этой колонки совпадают) document_1, document_2 и document_3.
Так как изначально таблица document ссылалась на bo, то у партиций мы должны восстановить эту связь для ссылочной целостности, т. е. для document_1 нужно сделать ссылку на bo_1 и т. д. Таблиц у меня с десяток, а партиций предполагается около 90. 900 связей руками прописывать тяжко.
Говоря про ссылку я понимаю внешний ключ (т. е. ограничение REFERENCES)
> но на сколько я понял он следит за заведением партиций
Вот, например:
https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman_howto_native.md#partitioning-an-existing-table
> колонка для партиционирования есть в обеих таблицах
И она не входит в PK и FK? Показали бы Вы конкретный пример (\d каждой из пары таблиц), это уж точнее, чем словами описывать...
> Таблиц у меня с десяток, а партиций предполагается около 90.
А зачем Вы это делаете, кстати? И какая версия PostgreSQL?
Вот, например:
https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman_howto_native.md#partitioning-an-existing-table
> колонка для партиционирования есть в обеих таблицах
И она не входит в PK и FK? Показали бы Вы конкретный пример (\d каждой из пары таблиц), это уж точнее, чем словами описывать...
> Таблиц у меня с десяток, а партиций предполагается около 90.
А зачем Вы это делаете, кстати? И какая версия PostgreSQL?
KT
Yaroslav Schekin
> но на сколько я понял он следит за заведением партиций
Вот, например:
https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman_howto_native.md#partitioning-an-existing-table
> колонка для партиционирования есть в обеих таблицах
И она не входит в PK и FK? Показали бы Вы конкретный пример (\d каждой из пары таблиц), это уж точнее, чем словами описывать...
> Таблиц у меня с десяток, а партиций предполагается около 90.
А зачем Вы это делаете, кстати? И какая версия PostgreSQL?
Вот, например:
https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman_howto_native.md#partitioning-an-existing-table
> колонка для партиционирования есть в обеих таблицах
И она не входит в PK и FK? Показали бы Вы конкретный пример (\d каждой из пары таблиц), это уж точнее, чем словами описывать...
> Таблиц у меня с десяток, а партиций предполагается около 90.
А зачем Вы это делаете, кстати? И какая версия PostgreSQL?
Входит. У меня составной ключ (sid, id) И в таблицах bo и в document есть этот ключ, при этом эти же колонки являются внешним ключом в document.
Версия 12.3
Делаю я это для потому, что у меня предполагается хранить большой объём данных (несколько терабайт).
bo document
-------- --------
+sid +#sid
+id +#id
Версия 12.3
Делаю я это для потому, что у меня предполагается хранить большой объём данных (несколько терабайт).
YS
Входит. У меня составной ключ (sid, id) И в таблицах bo и в document есть этот ключ, при этом эти же колонки являются внешним ключом в document.
Версия 12.3
Делаю я это для потому, что у меня предполагается хранить большой объём данных (несколько терабайт).
bo document
-------- --------
+sid +#sid
+id +#id
Версия 12.3
Делаю я это для потому, что у меня предполагается хранить большой объём данных (несколько терабайт).
Вот опять Вы пишете... так трудно \d показать (и указать поле/поля и вид партиционирования)? ;)
> Входит.
Если действительно так, то никаких отдельных ключей по partitions там просто не нужно.
> Версия 12.3
А уже должна быть 12.6. ;) Кстати, для партиционирования чем новее major версия, тем [существенно] лучше.
> Входит.
Если действительно так, то никаких отдельных ключей по partitions там просто не нужно.
> Версия 12.3
А уже должна быть 12.6. ;) Кстати, для партиционирования чем новее major версия, тем [существенно] лучше.
K
Добрый день
дан такой запрос
where au.filial_code in (00828,00827,00829,00823,00824,00826,00820,00822,00821,01132,01005,00830) GROUP BY au.id
значения в скобках сейчас в формате int но должны быть в varchar. Как можно закастить их ?
дан такой запрос
where au.filial_code in (00828,00827,00829,00823,00824,00826,00820,00822,00821,01132,01005,00830) GROUP BY au.id
значения в скобках сейчас в формате int но должны быть в varchar. Как можно закастить их ?
W
кавычки поставить.
YS
Добрый день
дан такой запрос
where au.filial_code in (00828,00827,00829,00823,00824,00826,00820,00822,00821,01132,01005,00830) GROUP BY au.id
значения в скобках сейчас в формате int но должны быть в varchar. Как можно закастить их ?
дан такой запрос
where au.filial_code in (00828,00827,00829,00823,00824,00826,00820,00822,00821,01132,01005,00830) GROUP BY au.id
значения в скобках сейчас в формате int но должны быть в varchar. Как можно закастить их ?
А почему просто запрос нормально не переписать?
Нормально — это с параметром / параметрами вместо вот этого вот. ;)
Нормально — это с параметром / параметрами вместо вот этого вот. ;)
K
кавычки поставить.
запрос с бекенда идет и не знаешь сколько значений будет в in
W
Так в бекэнде и проставить
YS
запрос с бекенда идет и не знаешь сколько значений будет в in
Непараметризованный запрос с backend?!
Что это за backend такой "прекрасный"?
Что это за backend такой "прекрасный"?
BO
SELECT COUNT(*) AS kkk FROM table WHERE created_at > date AND kkk > 5;
Почему альяс в условии не работает? Или есть ли замена этому запросу?
Почему альяс в условии не работает? Или есть ли замена этому запросу?