Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
join и вычисление массива через array(select... )
|
|||
|---|---|---|---|
|
#18+
есть запрос, которым я получаю двумерный массив обычным селектом и разбором строки: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Я никак не могу извлечь ParentArticleID вместе с масивом. Есть какая-нибудь возможность сделать JOIN по A.ParentArticleID , если вышеприведенный запрос будет после FROM ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2008, 15:32 |
|
||
|
join и вычисление массива через array(select... )
|
|||
|---|---|---|---|
|
#18+
плохо сформулировал последнюю фразу. я хотел бы сделать join этого запроса (возвращающего text[][]) с другими таблицами, но никак не могу вытащить наружу parentArticleID для объединения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2008, 15:39 |
|
||
|
join и вычисление массива через array(select... )
|
|||
|---|---|---|---|
|
#18+
Решение нашлось. Concat & Array обсуждалось тут: http://archives.postgresql.org/pgsql-sql/2007-12/msg00114.php в этой же ветке ссылка на примеры. http://www.zigo.dhs.org/postgresql/#comma_aggregate Проблема, повторюсь, в том, что операция array (select ...) не может принять из запроса произвольное поле. Запрос должен всегда возвращать 1 столбец. Агрегат же работает как функции max() min() etc только содержит в себе функцию обработчик (array_append), определение возвращаемого типа (anyarray) и исходное значение (пустой массив) создали агрегат Код: plaintext 1. 2. 3. 4. 5. 6. Теперь можем делать join таблицы товаров с готовыми массивами остатков (для каждого артикула возвращается прямогулосьная матрица). Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Такой же результат можно получить, если для каждого PA.ParentArticleID вызывать функцию, которая строит массив, но если таких вызовов много, то это будет очень медленно. И понятно почему. В запросе планировщик видит все таблицы и планирует запрос в целом. При вызове функции он строит план для отдачи PA.ParentArticleID и N раз строит план для вызова функции, которая N раз лезет в большую таблицу. На 6 товарах разница исполнения 1000мс для функций, 200мс для запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2008, 20:08 |
|
||
|
|

start [/forum/topic.php?fid=53&tid=2003884]: |
0ms |
get settings: |
9ms |
get forum list: |
20ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
69ms |
get topic data: |
13ms |
get forum data: |
4ms |
get page messages: |
56ms |
get tp. blocked users: |
2ms |
| others: | 253ms |
| total: | 436ms |

| 0 / 0 |
