|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
Добрый день. Есть необходимость перехватить и изменить SQL запрос SELECT в PostgreSQL. Помогите с информацией. TRIGGER не работает на SELECT. Заранее спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2019, 12:50 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
Вопрос слишком абстрактный. Приведите реальный пример для чего это нужно. Что вы собираетесь там менять? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2019, 13:02 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
DSKaluginВопрос слишком абстрактный. Приведите реальный пример для чего это нужно. Что вы собираетесь там менять? Есть запрос, который делает CROSS JOIN. Он выполняется ОЧЕНЬ долго. Я хочу его сделать через INNER JOIN, но у меня нет возможности изменять запрос через само ПО. Только СУБД. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2019, 13:29 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
_WeSTMan_DSKaluginВопрос слишком абстрактный. Приведите реальный пример для чего это нужно. Что вы собираетесь там менять? Есть запрос, который делает CROSS JOIN. Он выполняется ОЧЕНЬ долго. Я хочу его сделать через INNER JOIN, но у меня нет возможности изменять запрос через само ПО. Только СУБД. В такой постановке вопроса - никак. PS: я не очень понимаю как cross join можно на inner join заменить без изменения смысла запроса и результатов. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2019, 14:43 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
Maxim Boguk_WeSTMan_пропущено... Есть запрос, который делает CROSS JOIN. Он выполняется ОЧЕНЬ долго. Я хочу его сделать через INNER JOIN, но у меня нет возможности изменять запрос через само ПО. Только СУБД. В такой постановке вопроса - никак. PS: я не очень понимаю как cross join можно на inner join заменить без изменения смысла запроса и результатов. Текущий запрос: SELECT id FROM Archive, bid WHERE bid.id = Archive.id; Выполнение 6 сек. / Я хочу сделать так: SELECT id FROM Archive INNER JOIN bid ON Archive.id = bid.id; Выполнение 30 мсек. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2019, 15:04 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
Maxim BogukВ такой постановке вопроса - никак. а через https://www.postgresql.org/docs/current/rules.html такую задачу не сделать? сам с этим не сталкивался, тем более в PostgreSQL ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2019, 15:07 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
_WeSTMan_Maxim Bogukпропущено... В такой постановке вопроса - никак. PS: я не очень понимаю как cross join можно на inner join заменить без изменения смысла запроса и результатов. Текущий запрос: SELECT id FROM Archive, bid WHERE bid.id = Archive.id; Выполнение 6 сек. / Я хочу сделать так: SELECT id FROM Archive INNER JOIN bid ON Archive.id = bid.id; Выполнение 30 мсек. Эти два запроса эквивалентны для базы в том числе. Если у вас такая большая разница - приведите результаты explain analyze обоих запросов. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2019, 16:01 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
Leonid KudryavtsevMaxim BogukВ такой постановке вопроса - никак. а через https://www.postgresql.org/docs/current/rules.html такую задачу не сделать? сам с этим не сталкивался, тем более в PostgreSQL Через Rule подобную замену нельзя сделать потому что она семантику запроса меняет. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2019, 16:03 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
_WeSTMan_Maxim Bogukпропущено... В такой постановке вопроса - никак. PS: я не очень понимаю как cross join можно на inner join заменить без изменения смысла запроса и результатов. Текущий запрос: SELECT id FROM Archive, bid WHERE bid.id = Archive.id; Выполнение 6 сек. / Я хочу сделать так: SELECT id FROM Archive INNER JOIN bid ON Archive.id = bid.id; Выполнение 30 мсек. Вообще-то - это одно и то же. На чем ваш клиент написан, который выдает этот "неправильный" запрос? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2019, 16:34 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
Ролг Хупин_WeSTMan_пропущено... Текущий запрос: SELECT id FROM Archive, bid WHERE bid.id = Archive.id; Выполнение 6 сек. / Я хочу сделать так: SELECT id FROM Archive INNER JOIN bid ON Archive.id = bid.id; Выполнение 30 мсек. Вообще-то - это одно и то же. На чем ваш клиент написан, который выдает этот "неправильный" запрос? Анализ запроса с CROSS Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Применение INNER Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
CROSS делает таблицу x*x, а INNER встраивает. Если будет 100 записей в одном и 100 в другом, то будет 100*100 при кроссе, а при INNER будет суммарно 100 ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2019, 17:14 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
_WeSTMan_, Приведите не только планы, но и запросы. Т.е. полный вывод начиная с EXPLAIN ... Есть подозрения, что планы от других запросов, в частности в первом плане выполняется сортировка по bid.datefinished, о чем не говорилось. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2019, 17:26 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
Павел Лузанов_WeSTMan_, Приведите не только планы, но и запросы. Т.е. полный вывод начиная с EXPLAIN ... Есть подозрения, что планы от других запросов, в частности в первом плане выполняется сортировка по bid.datefinished, о чем не говорилось. CROSS запрос Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30.
INNER запрос Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31.
... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2019, 17:30 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
_WeSTMan_, А что делает DISTINCT в первом запросе? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2019, 17:35 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
Павел Лузанов_WeSTMan_, А что делает DISTINCT в первом запросе? Вот да... там разница не в типе JOIN а в наличии/отсутствии DISTINCT. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2019, 17:38 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
_WeSTMan_CROSS делает таблицу x*x, а INNER встраивает. Если будет 100 записей в одном и 100 в другом, то будет 100*100 при кроссе, а при INNER будет суммарно 100 это если условий на join нет.... в вашем случае запросы будут 100% одинаковы и по плану и по результатам... писать можно и так и эдак как кому нравится ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2019, 17:40 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
Павел Лузанов_WeSTMan_, А что делает DISTINCT в первом запросе? судя по спискам выдачи и сортировки и where Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25.
этот DISTINCT (неудачно) заменяет exists -- на случай множественности со стороны t1 (что судя по пкей на поле связи не соответствует случаю тс) судя по ["(1=1)" ] там самопальный "движок", аффтар коего упирается его переписывать. и пинает тс-а ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2019, 17:50 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
Maxim BogukЧерез Rule подобную замену нельзя сделать потому что она семантику запроса меняет. Amazon через pg-bouncer вроде такое делает https://aws.amazon.com/blogs/big-data/query-routing-and-rewrite-introducing-pgbouncer-rr-for-amazon-redshift-and-postgresql/ ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2019, 18:50 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev, Ну это не совсем то. Это замена не на сервере бд, а в промежуточном слое. Предлагается написать питоновскую функцию, которая может заменять текст запроса на любой другой запрос. Но это все происходит до того как запрос попал на сервер. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.10.2019, 20:57 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
Maxim Boguk_WeSTMan_CROSS делает таблицу x*x, а INNER встраивает. Если будет 100 записей в одном и 100 в другом, то будет 100*100 при кроссе, а при INNER будет суммарно 100 это если условий на join нет.... в вашем случае запросы будут 100% одинаковы и по плану и по результатам... писать можно и так и эдак как кому нравится Условие на JOIN есть. Посмотрите, пожалуйста, выше в пример INNER JOIN ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2019, 08:50 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
_WeSTMan_Maxim Bogukпропущено... это если условий на join нет.... в вашем случае запросы будут 100% одинаковы и по плану и по результатам... писать можно и так и эдак как кому нравится Условие на JOIN есть. Посмотрите, пожалуйста, выше в пример INNER JOIN "а ты упорный, парамоша (сс)" приведите планы для следующих запросов : "CROSS запрос" Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30.
INNER запрос Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31.
после чего перечитайте топек ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2019, 09:50 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
_WeSTMan_, вопрос неправильный и отвечают вам неправильно, потому что на неправильный вопрос. То, что вы хотите сделать, лишено смысла. У каждой программы есть автор (сюрприз) и исходный код (ещё сюрприз). Вот к автору и обращайтесь за изменением SQL-запроса и, если программа составлена по вашему заказу, то требуйте предоставления исходного кода (это надо сделать ещё до начала работы во избежание препирательств. Но если не сообразили, то препирайтесь). Сейчас вы можете попытаться ускорить выполнение запроса подбором индексом и/или замены таблицы, к которой он обращается, на view или materialized view. А если вы подберёте более эффективный SQL-запрос, то вместо бессмысленного перехвата прежнего запроса надо изменить программу. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2019, 10:23 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
Partisan M_WeSTMan_, вопрос неправильный и отвечают вам неправильно, потому что на неправильный вопрос. То, что вы хотите сделать, лишено смысла. У каждой программы есть автор (сюрприз) и исходный код (ещё сюрприз). Вот к автору и обращайтесь за изменением SQL-запроса и, если программа составлена по вашему заказу, то требуйте предоставления исходного кода (это надо сделать ещё до начала работы во избежание препирательств. Но если не сообразили, то препирайтесь). Сейчас вы можете попытаться ускорить выполнение запроса подбором индексом и/или замены таблицы, к которой он обращается, на view или materialized view. А если вы подберёте более эффективный SQL-запрос, то вместо бессмысленного перехвата прежнего запроса надо изменить программу. Система писалась давно. Разработчиков уже не существуют. Написано для glassfish. Нашим программистам очень сложно копаться в этом коде и не везде можно переделать SQL запросы. Некоторые сделаны через framework. Ищем решение на стороне БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2019, 10:26 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
_WeSTMan_Partisan M_WeSTMan_, вопрос неправильный и отвечают вам неправильно, потому что на неправильный вопрос. То, что вы хотите сделать, лишено смысла. У каждой программы есть автор (сюрприз) и исходный код (ещё сюрприз). Вот к автору и обращайтесь за изменением SQL-запроса и, если программа составлена по вашему заказу, то требуйте предоставления исходного кода (это надо сделать ещё до начала работы во избежание препирательств. Но если не сообразили, то препирайтесь). Сейчас вы можете попытаться ускорить выполнение запроса подбором индексом и/или замены таблицы, к которой он обращается, на view или materialized view. А если вы подберёте более эффективный SQL-запрос, то вместо бессмысленного перехвата прежнего запроса надо изменить программу. Система писалась давно. Разработчиков уже не существуют. Написано для glassfish. Нашим программистам очень сложно копаться в этом коде и не везде можно переделать SQL запросы. Некоторые сделаны через framework. Ищем решение на стороне БД. вы уже проверили планы с реверсом "дистинкта" или нет ? т.е. уже убедились в бессмысленности своего предприятия ? (и перестали пить коньяк по утрам ?) на стороне субд вам надо реализовать аналог луз-индекскана для дистинкт-лимит-а на уровне унутренних алгоритмов оптимизатора постгреса. (что алгоритмически несложно, если иметь в руках что-то типа seek , который обычно можно эмулировать в скл кляузой with recurive с бубнами и джек-потом , но как в общем случае анализировать статистику, чтобы выбрать такой или иной алгоритм -- надо думать , что не является сильной стороной разрабов планировщика пж ) , дабы подавить фатальное влияние DISTINCT на план. или же достаточно просто выбросить DISTINCT из запроса на стороне приложения. поскольку в данном конкретном случае он похоже не нужен -- в силу констрейнтов на таблицах. а план валит напрочь. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2019, 10:55 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
Maxim BogukПавел Лузанов_WeSTMan_, А что делает DISTINCT в первом запросе? Вот да... там разница не в типе JOIN а в наличии/отсутствии DISTINCT. Потерял DISTINCT во втором запросе, извините) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2019, 11:14 |
|
Перехват и изменение запроса SELECT
|
|||
---|---|---|---|
#18+
_WeSTMan_, Не надо извиняться, приведите полностью команду explain вместе с её выводом для обоих запросов. Пока планы были отдельно, запросы отдельно. И в показанных запросах находилось что-то неучтенное. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.11.2019, 12:53 |
|
|
start [/forum/topic.php?fid=53&fpage=35&tid=1994964]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
30ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
2ms |
others: | 11ms |
total: | 144ms |
0 / 0 |