2. индекс по полю A при условии A > 2019, индекс по полю (A,B) при условии A < 2019. Второй покрывает 1ый?
3. разобрался. спасибо.
4. в материальных представлениях нельзя делать PK, приходится делать уникальные индексы, вместо них. а скрипт выводит их в поиске как таблицы без pk.
проверил одну базу
1. на дубли индексов: нашёл индекс уникальный по полю и ограничение целостности (проверка поля на уникальность). Что из этого стоит удалить?
2. проверил на пересекающиеся индексы. есть индекс hash по полю А и btree по (A,B). ещё проблема, на индексах с условиями WHERE (условия разные, но скрипт считает их пересекающимися).
3. внешние ключи без индексов вообще не понял как работает.
ругнулся на одну табличку. но столбец на который ссылается внешний ключ хоть и не является PK, но содержит ограничение уникальности и входит на 1ой позиции в состав сложного индекса.
4. 'Tables without primary key' не находит PK на материализованных представлениях, где есть уникальный btree индекс по полю id.
Общие замечания:
1. можно что-нибудь придумать чтобы не вписывать каждый раз схему руками. например использовать дефолтную или public?
2. есть какие желаемые значения по bloat, после чего их стоит отправить на vacum?
как разберётесь в вопросе, тогда стоит писать об этом.
предложение пойти поискать в гугл и отсутствие у вас внятного опыта, вызывает недоверие к вашим постам.
Расскажите, про ограничения упрощёки в 2020 которые делают неприемлемой для большинства кейсов, очень интересно послушать.
с 1992 год тут всё сильно изменилось если что.
а потом приходят ограничениям от бизнеса (не вышли на прибыль, не подняли раунд и т.д.) и человека ждёт облом…
Не стоит обещать человеку то, за что вы не сами не отвечаете, и когда не управляете в полном объёме этим ресурсом, в данном случае финансовым.
В моменте мне кайфово, значит баланс правильный :)
ошибочное утверждение, если речь идёт о долгосрочном планировании.
Когда через N месяцев, начнёт выворачивать от работы, станет немного понятнее.
Можете сравнить себя по спортсменом, кто вечера проводит на тусовках, а утром выходит на поле, обычно они быстро заканчивают свою карьеру.
Многие проходили то, что вы пишите, некоторые учились на своих ошибках, кто-то успевал заранее разобраться в вопросе и подложить соломку.
это очевидно, но есть и общие моменты — например, повышение скорости доставки на 10%, повышает скорость проверки гипотез продактами, а это влияет на прибыль или капитализацию и т.д.
поэтому и задал вопрос, делали кто-нибудь такую модель, прежде чем вкладывать\закапывать деньги на подобные проекты.
Сейчас это выглядит больше как ИТишный проект с непрозрачной бизнес-ценностью.
А можно как-то сравнить экономическую составляющую.
Допустим: после перехода на k8s кол-во простоев выросло на Х%, это Y рублей, но также мы смогли заработать благодаря k8s N рублей и т.д.
Нигде не видел подробного экономического обоснования такого перехода.
Допустим для компаний уровня гугл и амазон, нет альтернативы. Но вот можно ли для авито сделать экономическое обоснование такого перехода, ведь и без него вы бы смогли работать.
т.е. чтобы дойти до бага, нужно пройти 3-4 сервиса на разных стеках.
3. разобрался. спасибо.
4. в материальных представлениях нельзя делать PK, приходится делать уникальные индексы, вместо них. а скрипт выводит их в поиске как таблицы без pk.
учетки на github нет.
1. на дубли индексов: нашёл индекс уникальный по полю и ограничение целостности (проверка поля на уникальность). Что из этого стоит удалить?
2. проверил на пересекающиеся индексы. есть индекс hash по полю А и btree по (A,B). ещё проблема, на индексах с условиями WHERE (условия разные, но скрипт считает их пересекающимися).
3. внешние ключи без индексов вообще не понял как работает.
ругнулся на одну табличку. но столбец на который ссылается внешний ключ хоть и не является PK, но содержит ограничение уникальности и входит на 1ой позиции в состав сложного индекса.
4. 'Tables without primary key' не находит PK на материализованных представлениях, где есть уникальный btree индекс по полю id.
Общие замечания:
1. можно что-нибудь придумать чтобы не вписывать каждый раз схему руками. например использовать дефолтную или public?
2. есть какие желаемые значения по bloat, после чего их стоит отправить на vacum?
надеюсь, нашёл что-то полезное.
предложение пойти поискать в гугл и отсутствие у вас внятного опыта, вызывает недоверие к вашим постам.
с 1992 год тут всё сильно изменилось если что.
наверное, может быть hash для поиска по =, и btree для остального.
www.gnicpm.ru/plasmatherapy
прошу прощения за долгий ответ :(
Не стоит обещать человеку то, за что вы не сами не отвечаете, и когда не управляете в полном объёме этим ресурсом, в данном случае финансовым.
ошибочное утверждение, если речь идёт о долгосрочном планировании.
Когда через N месяцев, начнёт выворачивать от работы, станет немного понятнее.
Можете сравнить себя по спортсменом, кто вечера проводит на тусовках, а утром выходит на поле, обычно они быстро заканчивают свою карьеру.
Многие проходили то, что вы пишите, некоторые учились на своих ошибках, кто-то успевал заранее разобраться в вопросе и подложить соломку.
поэтому и задал вопрос, делали кто-нибудь такую модель, прежде чем вкладывать\закапывать деньги на подобные проекты.
Сейчас это выглядит больше как ИТишный проект с непрозрачной бизнес-ценностью.
Допустим: после перехода на k8s кол-во простоев выросло на Х%, это Y рублей, но также мы смогли заработать благодаря k8s N рублей и т.д.
Нигде не видел подробного экономического обоснования такого перехода.
Допустим для компаний уровня гугл и амазон, нет альтернативы. Но вот можно ли для авито сделать экономическое обоснование такого перехода, ведь и без него вы бы смогли работать.