Насильственная оптимизация запросов PostgreSQL

[nitro2005]

Оно будет перехватывать запросы от приложения, написанного не на .NET и соединяющегося с PostgreSQL по TCP?

[nitro2005]

Понял. С .NET никогда не сталкивался, но спасибо:)

[nitro2005]

Потому что костыль — мое второе имя версия используемого ПО уже не поддерживается разработчиком, даже за деньги. Да и не будет он ради нас воротить партиционирование, т.к. это у него не самый важный продукт. Но к его чести, советы как лучше сделать партиционирование он все-таки дает, правда за деньги :)

[nitro2005]

Хехе, это уже не мой вопрос. Моим решением было бы очевидное — все переписать заново самостоятельно (по деньгам бы дешевле вышло чем поддержка+обновления до актуальных версий). Но бизнес к такому не готов :)

[gecube]

Краткий и дурацкий вопрос. Зачем это, если уже есть github.com/wgliang/pgproxy?

You can do:

* database read and write separation
* database services disaster recovery
* proxy database
* rewrite sql statement

[nitro2005]

Покажете как переписать на нем запрос?

[Ilya_ilf]

Только посредством оборачивания запроса в функцию. А внутри уже воротите, что хотите. Но, как я понял, в вашем случае это не спасёт. Слишком уж крива эта ваша «Закрытая система»

[ultrinfaern]

А скажите, пожалуйста, так как вы уже писали триггеры на таблицу, почему не написали триггер на DELETE, в котором можно было удаляемые данные отсаживать в другую таблицу. Плюс в том, что программа остаётся со своей структурой, а вы получаете полную свою таблицу.

[nitro2005]

Вариантов решения всегда много… Наверное, тогда просто опыта не хватило это сделать, хотя сейчас действительно это кажется верным вариантом. Но сейчас уже не хочется этим заниматься, т.к. все это в куче мест уже в эксплуатации. Поэтому и ищутся быстрые костыли :)

[Joka]

habr.com/company/oleg-bunin/blog/309330 — попробуйте так еще. вы можете все старые данные вынести на отдельный сервер просто.

[Naves]

Должно быть вот так
VALUES($1::varchar, $2::integer, $3::date)

Насколько вырастает производительность такого кода? Ведь тогда пропадает возможность относительно простого просмотра лога: «какие же там такие кривые значения вставляются, что потом все виснет»
В моем случае лет 5 назад была база firebird. Запросы смотрел через wireshark, а исправлять пришлось ковыряя исполняемый файл, где-то правкой строк и вставкой first 100 или where 1=2/*date=%s*/ или вообще ассемблерным хулиганством и вставкой MOV EAX,1; NOP вместо CALL очень важной функции, которая в десятый раз подряд узнает сколько же всего записей в бд
И это не считая создания индексов, про которые забыл разработчик.

[nitro2005]

Насчет производительности не скажу, теоретически парсеру меньше работы + появляется возможность кешировать результаты парсинга.
В документации указано, что главный плюс — это безопасность:

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 — с уже конкретными значениями или нет.

[kenjichka]

Почему не использовалось представление(view), внутри которого было бы нужное условие по дате(партиции)?

[nitro2005]

Не очень представляю как это поможет… Может я мысль не понял — уточните?

[kenjichka]

Я уже начал было писать, что имел ввиду, пока писал понял где ошибаюсь.

Вкратце: переименовать таблицу в prefix_tablename.
Затем создать представление с именем tablename, которое выбирает данные из prefix_tablename с условием по дате, а приложение выбирало бы данные из представления с условием по ID(или любому другому).
Не учел, что новые записи в таблицу заносит приложение.

[tgregory]

В постгресе вьюхи создаются посредством правил, т.е. создаётся таблица на которую вешается SELECT правило. Можно создать также INSERT, UPDATE, DELETE правила. Там есть ряд кривостей и ограничений, но в зависимости от того, как вам надо было переписывать запросы, можно было бы ограничиться переименованием таблиц и созданием таких вьюх. Обращаю внимание, что правила это не триггеры, а именно синтаксическое переписывание запроса.