|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
#40139989
![]() Ссылка:
Ссылка на сообщение:
Ссылка с названием темы:
Ссылка на профиль пользователя:
Ссылка на вложение:
Ссылка на вложение 2:
Ссылка на вложение 3:
|
||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
#18+
mssql2005 Всем привет! готовим udf mssql базы для переезда на postgresql (санкции да и вообще все морально устарело, win11 отрубила поддержку tls1.x, 'старого' sql драйвера и т.д. - 20ти летний серверный софт 'умирает' понемногу... денег на обновление не выделяют...) вопрос по оптимизации select - одним запросом выбираем id объектов + 20 (однотипных) left join подгоняем к ним значения атрибутов mssql справляется а postgresql (на той же базе/миграция на том же запросе) 'умирает'(резко тормозит) если left join более 8~10 оставив пока postgresql в стороне просто хочу попытаться ускорить выборку на mssql например через cte (поскольку left join берет инфу из одних и тех же 4х таблиц многократно) ... структура бд от вендора (не можем менять), используем базу лет 20ть проблем нет - работает, так что вопрос чисто по ускорению запроса 1. есть 3 таблицы значений атрибутов (id атрибута, значение атрибута и т.д.) для хранения строк, чисел и дат 2. есть одна таблица связи атрибутов с объектами (id объекта, id атрибута и т.д.) в left join я просто многократно обращаюсь к этим таблицам чтобы по id объекта (из основного запроса по выборке объектов) и id атрибута получить значение атрибута вот что мы использовали последние 20 лет Код: 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. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43.
вот тоже самое через cte Код: 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. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46.
вопрос чисто эмпирический - можно ли как то ускорить запрос многократно использующий в left join одни и те-же таблицы (в данном случае) каким либо другим подходом к выборке? или это все упирается в железо сервера? ps на mssql сейчас отдельная виртуалка winserver2003+mssql2005 (здесь по скорости все более менее, количество left join глотает нормально), на postgres просто виртуалка win8.1+posgresql16 (здесь все это вообще выглядит 'мертвым' при большом количестве left join) ... |
||||||||||||||||||||||
:
Нравится:
Не нравится:
|
||||||||||||||||||||||
12.02.2025, 12:19 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2025, 14:01 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
#40140001
![]() Ссылка:
Ссылка на сообщение:
Ссылка с названием темы:
Ссылка на профиль пользователя:
Ссылка на вложение:
Ссылка на вложение 2:
Ссылка на вложение 3:
|
||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
#18+
... |
||||||||||||||||||||||
:
Нравится:
Не нравится:
|
||||||||||||||||||||||
12.02.2025, 15:41 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
неожиданно на postgresql стрельнула вот такая конструкция Код: 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. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70.
(самая длинная таблица 9 562 038 строк - подрезаем ее через in = только нужные атрибуты = получается где то 2 700 099 - неважно...) говорим что материализация не нужна as NOT MATERIALIZED( типа в память упаковываем (как я понял) и дальше работаем с ней в запросе - выигрыш на коротких выборках = до 200 - на порядок, на длинных минимум в два раза быстрее в mssql нет эффекта - не нашел флага не материализовать - наверно аналог табличная переменная короче в памяти формируем блок и многократно его используем... ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2025, 17:41 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
В статье по EAV в википедии есть вариант конкретно для постгре (и для мс) https://en.wikipedia.org/wiki/Entity–attribute–value_model#PostgreSQL:_JSONB_columns Это переход на JSON хранение. Но он подразумевает изменение структуры, поэтому, возможно, не подойдет. Сам не пользовался, но судя по гуглу такой подход вполне используют. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2025, 20:21 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
Да, в той же статье есть еще всякие разные подходы оптимизации EAV. Отдельно описаны. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2025, 20:24 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
Тяпа-ляпа [игнорируется] ну не знаю... по факту так = в памяти получается быстрее - так оптимизатор их строит, в конечном счете убив неделю на разборки (вылавливая микросекунды на конструирование запроса), отправив все планы на анализ в https://explain.tensor.ru/ - получил только одну рекомендацию = добавить индексов ну и настроить железо под postgresql, и сам сервер постгрис в общем пока все печально ps пойду в их тему - postgres может там найду что Спасибо всем! ... |
|||
:
Изменено: 10.03.2025, 09:35 - ef1
Нравится:
Не нравится:
|
|||
10.03.2025, 09:31 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ef1 [игнорируется] Все джойны выполняются в памяти, если уж быть точным, даже если данные не в кэше, а на диске на начало выполнения запроса. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.03.2025, 12:15 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
Добрый день. Есть варианты оптимизации запроса, желательно пробовать на данных похожие на реальные. Можно ли получить скрипты на создания таблиц и обезличенные тестовые данные? Если не позволяет размер файлов прикрепить к форуму, можно ссылку на облако. Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2025, 11:14 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ArtToms [игнорируется] скрипты таблиц не проблема - а вот обезличенные данные - проблема - база коммерческая... в принципе запросы идут по 6 таблицам объекты + типы объектов + атрибуты(строковые + числа + дата/время) + связь объектов с атрибутами... да и в mssql все летает, основной трабл в postgresql (https://resql.ru/forum/topic.php?fid=53&tid=2187215) - цель именно там скорость получить в их оптимизаторе.. но за предложение спасибо)) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.03.2025, 09:23 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ef1 [игнорируется] Добрый день. Попробовать не могу, нет таблиц, хотя бы покажу, что я хотел попробовать. 1. Уменьшить число внешних соединений, выделил полужирным, можно попробовать заменить на внутреннее соединение (inner). Внешнее оставить только к rw, и так в других местах, уменьшаем в два раза. Должно повлиять на скорость выполнения. 2. В MSSQL внешние соединения удавалось сделать внутренними с помощью cross apply. Вот это я хотел попробовать. From lsdbo.Ric_Get_Select(2,100000038900005,'PSft, PHrd, PExp, PSrv, pPls','','',0,'') rw left join --select * From lsdbo.Ric_Get_Select(2,4000000015666,'PSft, PHrd, PExp, PSrv, pPls','','',0,'') rw left join LSDBO.attrib_value AS av ON rw.id = av.Object_ID AND av.Attrib_ID = 100004068400000 LEFT JOIN LSDBO.value_string AS vv ON av.Value_ID = vv.id AND av.Attrib_ID = 100004068400000 left join LSDBO.attrib_value AS av1 ON rw.id = av1.Object_ID AND av1.Attrib_ID = 3000000000101 LEFT JOIN LSDBO.value_string AS vv1 ON av1.Value_ID = vv1.id AND av1.Attrib_ID = 3000000000101 LEFT JOIN ... |
|||
:
Нравится:
Не нравится:
|
|||
12.03.2025, 09:53 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ef1 [игнорируется] А можно хотя бы скрипты таблиц? Можно оставить только поля указанные в запросе, попробую накидать тестовые данные. Есть еще один вариант изменения запроса, хочу попробовать. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.03.2025, 13:21 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ef1 [игнорируется] что мешает вытянуть сначала все объекты и все их атрибуты и поверх PIVOT (для PG crosstab)? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.03.2025, 01:24 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
#40140346
![]() Ссылка:
Ссылка на сообщение:
Ссылка с названием темы:
Ссылка на профиль пользователя:
Ссылка на вложение:
|
||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
#18+
ShIgor [игнорируется] в общем то ничего за исключением переменной длины столбцов и динамического crosstab в postgresql - изучаю как раз не подскажите синтаксис pivot для поворота на примере t-sql запроса cte объект и его атрибуты Код: 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.
... |
||||||||||||||||
:
Изменено: 13.03.2025, 10:09 - ef1
Нравится:
Не нравится:
|
||||||||||||||||
13.03.2025, 10:07 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ArtToms [игнорируется] предлагаю через удаленный рабочий стол (например anydesk) посмотреть в MS студии - так будет проще всего - напишите zaytsev@cad.ru - потестим ? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.03.2025, 10:23 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ef1 [игнорируется] упс... к сожалению pivot попробовать здесь не могу = база старая sql compatibility level = server 2000(80) - удалось переехать только на 2005, уровень совместимости поднять не могу (( нет лицензий хотя-бы на 2008 так что мы в пролете )) - это одна из причин 'бегства' на PostgreSQL.... ... |
|||
:
Нравится:
Не нравится:
|
|||
13.03.2025, 10:46 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ef1 [игнорируется] наверное переменной не длины, а переменного количества столбцов атрибутов у разных объектов? это решается перечислением всех возможных вариантов для каждого объекта, т.е. в плоской таблице у каждого объекта должно быть то количество строк атрибутов, сколько всего столбцов планируется в Pivot вне зависимости, есть они физически у объекта или нет, даже в том случае если объект вообще не имеет атрибутов, например при необходимости вывести 15 атрибутов в столбцы, каждый объект должен иметь 15 строк атрибутов. пример pivot? в интернете вариантов масса, он каждый получается уникальный.. могу набросать с вашими метаданными.. сейчас только времени нет, на досуге.. а, ну и в PG не силен, только знаю что он (PG) есть :) ... |
|||
:
Изменено: 13.03.2025, 11:17 - ShIgor
Нравится:
Не нравится:
|
|||
13.03.2025, 11:16 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
нет лицензий хотя-бы на 2008 ... |
|||
:
Нравится:
Не нравится:
|
|||
13.03.2025, 11:21 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
к сожалению pivot попробовать здесь не могу ... |
|||
:
Нравится:
Не нравится:
|
|||
13.03.2025, 11:23 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ShIgor [игнорируется] спасибо!!! в ожидании досуга, пробую разобраться (смущает только требование функции агрегации, а в моем случае агрегировать в общем то нечего) - ps примеров да - навалом, да и 2005 оказалось поддерживает pivot, ок... до связи! ... |
|||
:
Нравится:
Не нравится:
|
|||
13.03.2025, 12:13 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
На postgresql создал тестовые таблицы для выполнения запросов, теперь есть на чем пробовать запросы. Привожу вариант преобразования внешнего соединения во внутреннее. На MSSQL, такая замена значительно увеличивала скорость выполнения запросов. Привожу запросы на postgresql. Переделал фрагмент из вашего запроса и новый вариант. Непонятно зачем вот это условие AND av.Attrib_ID = 100004068400000 в left join value_string AS vv? Отметил полужирным, поставил комментарий, у меня на результаты не повлияло. Интересно на боевой базе данные изменятся? В вашем запросе можно переделать подобным образом все аналогичные блоки. Попробуйте переделайте весь запрос и попробуйте на боевой базе. Интересно как изменится скорость на postgresql? Цитата [игнорируется] select rw.id, vv.value
From Ric_Get_Select (2,100000038900005,'PSft, PHrd, PExp, PSrv, pPls','','',0,'') rw
left join attrib_value AS av ON rw.id = av.Object_ID AND av.Attrib_ID = 100004068400000
left join value_string AS vv ON av.Value_ID = vv.id --AND av.Attrib_ID = 100004068400000
order by rw.id Цитата [игнорируется] select rw.id, vv.value
From Ric_Get_Select (2,100000038900005,'PSft, PHrd, PExp, PSrv, pPls','','',0,'') rw
cross join lateral (select max(vvv.value) as value
from attrib_value av
inner join value_string vvv on av.Value_ID = vvv.id
where rw.id = av.Object_ID
and av.Attrib_ID = 100004068400000) vv
order by rw.id ... |
|||
:
Изменено: 13.03.2025, 20:56 - ArtToms
Нравится:
Не нравится:
|
|||
13.03.2025, 20:53 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ArtToms [игнорируется] !!! щас буду пробовать вот скрипты таблиц (но лучше конечно на удаленном столе подключится к реальной базе и MSSQL и PostgreSQL - базы идентичны = была миграция средствами разработчика = владельца структуры данных БД ) MSSQL object_reference - таблица объектов Код: 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. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49.
object_type- таблица типов объектов Код: 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. 32. 33. 34. 35. 36. 37. 38. 39. 40.
attrib_value - таблица связей объектов и атрибутов Код: 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. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45.
value_string - таблица строковых значений атрибутов Код: 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. 32. 33.
value_numeric - таблица числовых значений атрибутов Код: 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. 32.
value_datetime- таблица дата время значений атрибутов Код: 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. 32.
object_reference - таблица объектов Код: 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. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65.
object_type- таблица типов объектов Код: 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. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45.
attrib_value - таблица связей объектов и атрибутов Код: 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. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74.
value_string - таблица строковых значений атрибутов Код: 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. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41.
value_numeric - таблица числовых значений атрибутов Код: 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. 32. 33. 34. 35. 36. 37. 38. 39. 40.
value_datetime- таблица дата время значений атрибутов Код: 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. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48.
индексы ric- в postgresql - мои по рекомендациям от https://explain.tensor.ru/ - типа к делу не относятся ... |
|||
:
Изменено: 14.03.2025, 09:18 - ef1
Нравится:
Не нравится:
|
|||
14.03.2025, 09:15 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
#40140361
![]() Ссылка:
Ссылка на сообщение:
Ссылка с названием темы:
Ссылка на профиль пользователя:
Ссылка на вложение:
Ссылка на вложение 2:
|
|||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
#18+
ArtToms [игнорируется] тесты по запросу из начала топика - по первому предложению (в общем то и там и там одно и тоже - наиболее 'полный по ограничениям' запрос чуть быстрее) mssql 2005 (10 выборок, база рабочая кешированная)postgres16 (~5 выборок, тестовая база - практически не кешированная)щас второе подготовлю внутреннее соединение... ... |
|||||||||||||||||||
:
Нравится:
Не нравится:
|
|||||||||||||||||||
14.03.2025, 10:02 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
#40140362
![]() Ссылка:
Ссылка на сообщение:
Ссылка с названием темы:
Ссылка на профиль пользователя:
Ссылка на вложение:
Ссылка на вложение 2:
|
|||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
#18+
ArtToms [игнорируется] во по планам по запросам по второму без --AND av.Attrib_ID = 100004068400000 mssqlpostgresqlexplain analyze ->https://explain.tensor.ru/ название pg_test_zaytsev_01 - не знаю откроется по ссылке или нет (публичный архив simple plan) https://explain.tensor.ru/archive/explain/bc5285eb94ce30b11d55bd4105a1f75a:0:2025-03-14#explain ... |
|||||||||||||||||||
:
Нравится:
Не нравится:
|
|||||||||||||||||||
14.03.2025, 10:22 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
#40140364
![]() Ссылка:
Ссылка на сообщение:
Ссылка с названием темы:
Ссылка на профиль пользователя:
Ссылка на вложение:
Ссылка на вложение 2:
Ссылка на вложение 3:
Ссылка на вложение 4:
|
|||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
#18+
ArtToms [игнорируется] НЕВЕРОЯТНО!!!!!! на PostgreSQL ускоренный вариант ->>> на порядок быстрее!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! postgresql 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. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122.
https://explain.tensor.ru/archive/explain/14275a45d875065152fa731c2f315dae:0:2025-03-14#explain и план какой красивый!!!------------------------------------------------------------------------- в двух словах - какая основная идея этого варианта в PostgreSQL? как получилось такое шикарное ускорение - нужно ли добавлять 'синтаксический сахар' CTE (с материализацией или без) или какой другой для красоты - нужно ли для данной структуры данных донастроить config posygresql - сейчас такой (немного памяти добавил по сравнению с коробочной настройкой) ... |
|||||||||||||||||||||||||
:
Нравится:
Не нравится:
|
|||||||||||||||||||||||||
14.03.2025, 11:29 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
#40140365
![]() Ссылка:
Ссылка на сообщение:
Ссылка с названием темы:
Ссылка на профиль пользователя:
Ссылка на вложение:
|
||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
#18+
... |
||||||||||||||||
:
Нравится:
Не нравится:
|
||||||||||||||||
14.03.2025, 12:06 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
Добрый день. Для меня такой результат ожидаемый, я таким способом в mssql часто пользуюсь, мне было интересно как это будет на PostgreSQL. Собственно, идея простая, заменить внешние объединения на внутренние. С внутренними проще сделать более оптимальный запрос. Это хорошо для любого sql сервера, так что и на других должно работать быстрее. В mssql аналог: cross apply. Есть еще способ перевода на внутреннее и без cross apply, но так проще и красивее. Если интересно, попробую рассказать, да и не у всех есть cross apply или такой аналог. Спасибо за подробные результаты тестов. ... |
|||
:
Изменено: 14.03.2025, 16:09 - ArtToms
Нравится:
Не нравится:
|
|||
14.03.2025, 16:07 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2025, 16:45 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ef1 [игнорируется] Если будут еще интересные места, попробую помочь. Мне возможно светит переход с mssql на PostgreSQL, потому такие задачки еще и полезны. А на PostgreSQL точно переходите или если mssql поправите проблемы, то откажитесь от перехода? К примеру, если база и нагрузка позволяет, можно использовать более поздние редакции бесплатной ExpressEdition. Тогда получите новые фишки, сможете поднять уровень совместимости базы и будет меньше хлопот . Удачи. ... |
|||
:
Изменено: 14.03.2025, 18:47 - ArtToms
Нравится:
Не нравится:
|
|||
14.03.2025, 18:46 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ArtToms [игнорируется] 1. переходить будем точно, еще 2 года назад планировали, последней каплей стало то что наши win клиенты с выходом win11 отрубились от базы, пришлось остаться на win10 (microsoft планомерно отключает старые tls, драйвера odbs mssql и т.д.)(к счастью мы пофиксили и то и другое - через реестр и удаление всех sql драйверов win11 и установку нужного от 2005 mssql... но ведь они обязательно еще что нибудь подкинут) 2. на счет ms express - сразу как они включили поддержку linux - поставили 12й(или 14й - не помню) - но ограничения по железу в экспрессе = низкая скорость = отказались - но используем в качестве резерва - каждую ночь туда основной бекап восстанавливаем - типа на всякий случай -------------- в итоге можно было бы успокоиться еще на пару лет но 3. политические разборки.. практически все уходят на открытые системы, и вендоры и юзеры (для меня например показатель переход ржд с oracle) -------------- к счастью руководство понимает что в конторе должен быть свой бэк/локальная база в противовес облачным монстрам Битрикс24 (которые даже бекапы не отдают)) ), а раз так и денег на серверный софт нет = дорога одна = на postgresql на llinux - к сожалению в один конец - в общем нужно остаться на волне и желательно бесплатно - поэтому только вперед)) ... |
|||
:
Изменено: 15.03.2025, 09:52 - ef1
Нравится:
Не нравится:
|
|||
15.03.2025, 09:48 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ArtToms [игнорируется] нет предела совершенству )) пытался сократить текст запроса Код: SQL 1. 2. 3. 4. 5. 6.
Код: SQL 1.
Код: SQL 1. 2. 3. 4.
2. делал через cte нематериализованный Код: SQL 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
Код: SQL 1. 2.
3. в итоге поменял внутри inner на left Код: SQL 1. 2. 3. 4. 5. 6.
единственное что не понял зачем max(vvv.value)... но без него результат короче получается по строкам короче самый красивый план и скорость при запросе в лоб!)) без извращений ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2025, 16:10 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ef1 [игнорируется] а вот еще интересный момент идем по двум объектам = к первому подгоняем связанный синтаксис mssql Код: 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. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49.
cross inner join Код: 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. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82.
второй - время планирования 18 мс + выполнения 13 сек план и диаграмма тоже в порядке https://explain.tensor.ru/archive/explain/787fe39e71ec68a7709aaae6b4275c92:0:2025-03-15#schema т.е когда к одному объекту подгоняем атрибуты - все ок, а к нескольким... не получается ускорится... ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2025, 19:02 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
Добрый день. С max, cross join lateral гарантировано возвратит одну запись, даже если результаты не найдутся (подобно left). Без него может сократиться число возвращаемых записей, похоже пробовали. В 'том то и есть изюминка. Пример, в таблице Table1 в поле id есть только положительные значения. Запрос select id from Table1 where id < 0 не вернет ни одной записи А select max(id) as id from Table1 where id < 0 вернет одну ЗАПИСЬ с пустым значением. Применять такой способ, можно если ожидаем только одну запись для каждого id. ... |
|||
:
Изменено: 15.03.2025, 19:17 - ArtToms
Нравится:
Не нравится:
|
|||
15.03.2025, 19:07 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ArtToms [игнорируется] тему наверно закроем - каждый postgresql запрос (или его часть) нужно трассировать отдельно, хорошо у нас в базе аналитики нет ))) халява mssql кончилась)) ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2025, 11:16 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
халява mssql кончилась остальное - страхи параноиков среди менеджеров, безопасников и иже с ними. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2025, 12:11 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ArtToms [игнорируется] вопросик, может подскажешь вот три одинаковых выборки postgresql вариант_1 каждый атрибут читается отдельно - по твоему варианту Код: 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. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49.
много повторов >> устраните повторное выполнение одинакового кода с помощью сохранения результата или совместного вычисления значений >>сильно расходится плановая и фактическая статистика по таблице, стоит выполнить ее ANALYZE "Planning Time: 12.753 ms" "Execution Time: 15175.654 ms" https://explain.tensor.ru/archive/explain/df6925c777c7935812897d4ee62218fa:0:2025-03-23#explain по рекомендации тензора https://habr.com/ru/companies/tensor/articles/574330/ - убрал повторные чтения вариант_2 left join все атрибуты читаются кучей и разворачиваются pivot Код: 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. 32. 33. 34. 35. 36. 37. 38. 39.
ни одного повтора но >>сильно расходится плановая и фактическая статистика по таблице, стоит выполнить ее ANALYZE "Planning Time: 1.804 ms" "Execution Time: 19964.939 ms" https://explain.tensor.ru/archive/explain/343bc8c6b72b3e6fba8077e240e3ff89:0:2025-03-23#explain вариант_3 cross join все атрибуты читаются кучей и разворачиваются pivot Код: 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. 32. 33. 34. 35. 36. 37. 38. 39.
ни одного повтора но >>сильно расходится плановая и фактическая статистика по таблице, стоит выполнить ее ANALYZE "Planning Time: 1.906 ms" "Execution Time: 20397.222 ms" https://explain.tensor.ru/archive/explain/7a09702799792190105d94db06ddbd38:0:2025-03-23#explain вопрос - вариант 1 самый быстрый потому что планировщик ошибся на ~1000, остальные тормозят т.к. ошибка уже на ~10000 - но при этом они чище... vaсuum и analyze таблиц из выборки не помогли (https://habr.com/ru/companies/tensor/articles/479656/) типа тупик? в данном конкретном случае - варианты 2 и 3 проще и планируются на порядок быстрее но выполняются... - не хватает железа? или настройки какой то вариант 1 грязноват и план длиннее - но уже пофиг на ресурсы.... не знаю в какую сторону и смотреть ... типа главное план сделать красивым и смотреть конфиг сервера или планом не заморачиваться и в конфиг не закапываться ... ... |
|||
:
Изменено: 23.03.2025, 18:35 - ef1
Нравится:
Не нравится:
|
|||
23.03.2025, 18:26 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
mssql2005 Всем привет! готовим udf mssql базы для переезда на postgresql (санкции да и вообще все морально устарело, win11 отрубила поддержку tls1.x, 'старого' sql драйвера и т.д. - 20ти летний серверный софт 'умирает' понемногу... денег на обновление не выделяют...) вопрос по оптимизации select - одним запросом выбираем id объектов + 20 (однотипных) left join подгоняем к ним значения атрибутов mssql справляется а postgresql (на той же базе/миграция на том же запросе) 'умирает'(резко тормозит) если left join более 8~10 оставив пока postgresql в стороне просто хочу попытаться ускорить выборку на mssql например через cte (поскольку left join берет инфу из одних и тех же 4х таблиц многократно) ... структура бд от вендора (не можем менять), используем базу лет 20ть проблем нет - работает, так что вопрос чисто по ускорению запроса 1. есть 3 таблицы значений атрибутов (id атрибута, значение атрибута и т.д.) для хранения строк, чисел и дат 2. есть одна таблица связи атрибутов с объектами (id объекта, id атрибута и т.д.) в left join я просто многократно обращаюсь к этим таблицам чтобы по id объекта (из основного запроса по выборке объектов) и id атрибута получить значение атрибута вот что мы использовали последние 20 лет Код: 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. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43.
вот тоже самое через cte Код: 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. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46.
вопрос чисто эмпирический - можно ли как то ускорить запрос многократно использующий в left join одни и те-же таблицы (в данном случае) каким либо другим подходом к выборке? или это все упирается в железо сервера? ps на mssql сейчас отдельная виртуалка winserver2003+mssql2005 (здесь по скорости все более менее, количество left join глотает нормально), на postgres просто виртуалка win8.1+posgresql16 (здесь все это вообще выглядит 'мертвым' при большом количестве left join) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2025, 09:19 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ef1 [игнорируется] Восстановил прежний логин, ArtToms был временный. Пытаюсь понять зачем в первом запросе внутреннее соединение заменили на left join LSDBO.attrib_value? Я специально обернул внешние соединения в cross join lateral, заменив на внутренние. Так возросла скорость и "выправился" план запросов. По поводу повторов. Проанализировал исходный запрос, можно попробовать вариант с временными таблицами. Первый запрос во временную таблицу. Отбираем записи из attrib_value, с av.attrib_id перечисленными в исходном запросе. Условие where av.attrib_id in (.....), я привел для примера, лучше сделать join из значений. Код: SQL 1. 2. 3. 4.
К таблицам БД, будет всего 4 запроса, остальное с временными. Вместо временных можно попробовать cte Написал очень упрощенно, если интересно, поясню подробнее, можно пообщаться и голосом. ... |
|||
:
Изменено: 27.03.2025, 17:28 - Alex_Toms
Нравится:
Не нравится:
|
|||
27.03.2025, 17:11 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
Alex_Toms [игнорируется] честно говоря я уже запутался окончательно, но вышел на шаблон который наверно буду использовать на все про все (уже очень много времени потерял... на все это) голосом созвонится - не поможет )), бекап базы дать postgresql тоже не вариант - может не развернутся (я на 16 и 17 версии тестирую) проще удаленно подключится (в любое время в онлайне, просто время согласовать) типовой шаблон основной объект+ связанные + все их атрибуты (выборка Total rows: 39071хcols: 57 Query complete 00:01:46.296 (это без внешних функций - с ними наверно минут на 50)) - в cte набираю объекты (id и фильтрация) - в cte добавляю вызовы внешних функций - это убивает все (наверно вызовы на клиента перенесу...) - при чтении cte подгоняю к этим id значения атрибутов (и вызов результатов внешних функций...) итоговый шаблон Код: 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. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. 267. 268. 269. 270. 271. 272. 273. 274. 275. 276. 277. 278. 279. 280. 281. 282. 283. 284. 285. 286. 287. 288. 289. 290. 291. 292. 293. 294. 295. 296. 297. 298. 299. 300. 301. 302. 303. 304. 305. 306. 307. 308. 309. 310. 311. 312. 313. 314. 315. 316. 317.
... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2025, 11:35 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ef1 [игнорируется] Добрый день. это без внешних функций - с ними наверно минут на 50 Что это? Сделал вариант первого запроса, сгруппировал атрибуты, получилось три запроса к базе. Интересно попробовать на реальных данных. Время выполнения и правильно ли выводит данные? Спойлер Код: 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. 32. 33.
... |
|||
:
Изменено: 30.03.2025, 10:22 - Alex_Toms
Нравится:
Не нравится:
|
|||
30.03.2025, 10:20 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
Alex_Toms [игнорируется] !!!круто, да чуть быстрее и план чистый (без повторов) как с pivot СПАСИБО. сейчас с этим типом запроса объектов одного типа и их атрибутами - проблем практически не осталось (ps 1. from attrib_value av inner join value_string v менял на from value_string v left join attrib_value av поскольку attrib_value очень большая ~9 000 000 строк а таблицы дат чисел и строк значительно короче.. типа гонки за микросекундами 2. >>это без внешних функций - с ними наверно минут на 50 - это в результатах итоговой select выборки - читаю вспомогательные данные из udf - подзапросы короче - в mssql теже тормоза - мои проблемы ) сейчас основная засада когда делаю запрос по нескольким объектам через left join с подгонкой атрибутов к ним в итоге в двух словах 1. если сначала собрать все id разных типов объектов в одном cte и дальше при его чтении бомбить таблицы атрибутов = более менее быстро Спойлер Код: 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. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249.
имел в виду вот этот тормоз - просто общий смысл показать Спойлер Код: 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. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253.
... |
|||
:
Изменено: 31.03.2025, 14:07 - ef1
Нравится:
Не нравится:
|
|||
31.03.2025, 14:04 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ef1 [игнорируется] Добрый день. В моем запросе после выкладке увидел опечатку, Дважды указан код 100003121500000. Убрать , max(case when av.Attrib_ID = 100003121500000 then v.value end) as ds100003121500000 и из and av.Attrib_ID in ( Мой косяк однако. Как я понял, у вас сейчас второй вариант. На вскидку, попробовать убрать внешние объединения. Получилось ведь найти более оптимальный вариант первого запроса без внешних объединений и повторов. Посмотрю на досуге, может что нибудь придумаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2025, 16:35 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ArtToms [игнорируется] привет, начали усиленный переход, подготовку mssql>postgresql кроме синтаксиса, у нас в бд нужно в платформе переписать формы объектов с вызовами SQL и скрипты(vbscript) в действиях(макросах) над объектами с вызовами SQL выяснился интересный момент по динамическим запросам postgresql вызываемых из vbscript может подскажешь? специально здесь написал - чтобы адресно проблема в фильтрации where причем проблемные запросы в pgadmin работают(фильтруют) а из скрипта нет вот так подключаемся Код: VBScript 1. 2. 3.
Код: VBScript 1.
динамический запрос в таком синтаксисе не фильтрует Код: PL/pgSQL 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Код: PL/pgSQL 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
у меня даже мыслей нет никаких))) сначала думал дело в русских буквах но нет... возможно строка подключения или сам объект ADODB должен быть другой... не знаю - ... может есть какие нибудь мысли на этот счет? ... |
|||
:
Изменено: 05.06.2025, 19:10 - ef1
Нравится:
Не нравится:
|
|||
05.06.2025, 19:07 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ef1 [игнорируется] нашел (ошибка типа copy/paste... скриптов из базы в базу) короче в проблемном запросе читал из вьюшки _view - в нормальном напрямую из таблицы _view возвращала тип сравниваемого столбца типа text а таблица character varyng(255) и сравнение vv0.value = 'Менеджер' с типом текст (при внешнем обращении через объект "ADODB.Connection","ADODB.Recordset") не работало а с типом (конвертация) vv0.value::varchar = 'Менеджер' работает убило то что PgAdmin работает в сравнении нормально так (без конвертации) и так (с конвертацией) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.06.2025, 09:50 |
|
|
start [/forum/topic.php?all=1&fid=46&tid=2187185]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
49ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
78ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 192ms |
0 / 0 |