Комментарии 20
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Потому что костыль — мое второе имя версия используемого ПО уже не поддерживается разработчиком, даже за деньги. Да и не будет он ради нас воротить партиционирование, т.к. это у него не самый важный продукт. Но к его чести, советы как лучше сделать партиционирование он все-таки дает, правда за деньги :)
Краткий и дурацкий вопрос. Зачем это, если уже есть github.com/wgliang/pgproxy?
You can do:
* database read and write separation
* database services disaster recovery
* proxy database
* rewrite sql statement
А скажите, пожалуйста, так как вы уже писали триггеры на таблицу, почему не написали триггер на DELETE, в котором можно было удаляемые данные отсаживать в другую таблицу. Плюс в том, что программа остаётся со своей структурой, а вы получаете полную свою таблицу.
habr.com/company/oleg-bunin/blog/309330 — попробуйте так еще. вы можете все старые данные вынести на отдельный сервер просто.
Должно быть вот так
VALUES($1::varchar, $2::integer, $3::date)
Насколько вырастает производительность такого кода? Ведь тогда пропадает возможность относительно простого просмотра лога: «какие же там такие кривые значения вставляются, что потом все виснет»
В моем случае лет 5 назад была база firebird. Запросы смотрел через wireshark, а исправлять пришлось ковыряя исполняемый файл, где-то правкой строк и вставкой first 100 или where 1=2/*date=%s*/ или вообще ассемблерным хулиганством и вставкой MOV EAX,1; NOP вместо CALL очень важной функции, которая в десятый раз подряд узнает сколько же всего записей в бд
И это не считая создания индексов, про которые забыл разработчик.
Насчет производительности не скажу, теоретически парсеру меньше работы + появляется возможность кешировать результаты парсинга.
В документации указано, что главный плюс — это безопасность:
А чтобы все висло из-за значений… ну не знаю. Это постараться надо :)
На досуге надо глянуть, интересно как отобразится такой запрос в pg_stat_activity — с уже конкретными значениями или нет.
В документации указано, что главный плюс — это безопасность:
The primary advantage of PQexecParams over PQexec is that parameter values can be separated from the command string, thus avoiding the need for tedious and error-prone quoting and escaping.… has some usefulness as an extra defense against SQL-injection attacks.
А чтобы все висло из-за значений… ну не знаю. Это постараться надо :)
На досуге надо глянуть, интересно как отобразится такой запрос в pg_stat_activity — с уже конкретными значениями или нет.
Почему не использовалось представление(view), внутри которого было бы нужное условие по дате(партиции)?
Не очень представляю как это поможет… Может я мысль не понял — уточните?
Я уже начал было писать, что имел ввиду, пока писал понял где ошибаюсь.
Вкратце: переименовать таблицу в prefix_tablename.
Затем создать представление с именем tablename, которое выбирает данные из prefix_tablename с условием по дате, а приложение выбирало бы данные из представления с условием по ID(или любому другому).
Не учел, что новые записи в таблицу заносит приложение.
Вкратце: переименовать таблицу в prefix_tablename.
Затем создать представление с именем tablename, которое выбирает данные из prefix_tablename с условием по дате, а приложение выбирало бы данные из представления с условием по ID(или любому другому).
Не учел, что новые записи в таблицу заносит приложение.
В постгресе вьюхи создаются посредством правил, т.е. создаётся таблица на которую вешается SELECT правило. Можно создать также INSERT, UPDATE, DELETE правила. Там есть ряд кривостей и ограничений, но в зависимости от того, как вам надо было переписывать запросы, можно было бы ограничиться переименованием таблиц и созданием таких вьюх. Обращаю внимание, что правила это не триггеры, а именно синтаксическое переписывание запроса.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Насильственная оптимизация запросов PostgreSQL