Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Неоптимальное использование WHERE в VIEW
|
|||
|---|---|---|---|
|
#18+
Добрый день. Не могу понять, есть VIEW: Код: plaintext 1. 2. 3. 4. 5. 6. 7. Запрос вида: Код: plaintext выполняется больше минуты. Если перенести WHERE в сам запрос, т.е. Код: plaintext 1. 2. 3. 4. 5. 6. 7. и соответственно оформить все это в виде функции, то работает меньше двух секунд. Не могу понять, почему движок обрабатывает по разному WHERE в самом SELECT-е, и внешний WHERE. Что можно сделать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2008, 13:38 |
|
||
|
Неоптимальное использование WHERE в VIEW
|
|||
|---|---|---|---|
|
#18+
где explain analyze проблемного запроса ? где версия сервера ? -- „Истина — это вовсе не то, что можно убедительно доказать, это то, что делает всё проще и понятнее“ — Антуан де Сент-Экзюпери ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2008, 15:06 |
|
||
|
Неоптимальное использование WHERE в VIEW
|
|||
|---|---|---|---|
|
#18+
PostgreSQL 8.2.6 explain analyze select * from view_name WHERE "min" BETWEEN '2008-08-07' AND '2008-08-08'; Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Уносим where внутрь view и вызываем: explain analyze select * from view_name; Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2008, 15:14 |
|
||
|
Неоптимальное использование WHERE в VIEW
|
|||
|---|---|---|---|
|
#18+
Robert Ayrapetyan: Заменяешь HAVING на WHERE -- не только план, но и результат будет другой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2008, 16:00 |
|
||
|
Неоптимальное использование WHERE в VIEW
|
|||
|---|---|---|---|
|
#18+
а где вы там нашли HAVING ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2008, 16:02 |
|
||
|
Неоптимальное использование WHERE в VIEW
|
|||
|---|---|---|---|
|
#18+
Robert Ayrapetyanа где вы там нашли HAVING Ну а что такое "min"? Агрегированное значение. Если запрос строить без вьюхи, то его без HAVING не проверишь. А в "оптимизированном" запросе проверяется не "min", а другое поле, которое не имеет отношение к проверке "min". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2008, 16:22 |
|
||
|
Неоптимальное использование WHERE в VIEW
|
|||
|---|---|---|---|
|
#18+
не пойму, что и где менять то? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2008, 16:46 |
|
||
|
Неоптимальное использование WHERE в VIEW
|
|||
|---|---|---|---|
|
#18+
Robert Ayrapetyanне пойму, что и где менять то?подумайте, в первом варианте Вы сравниваете дату с результатом выполнения функции, а во втором варианте - сравниваете дату со значением поля. это по определению разные условия и как следствие - разный результат запроса. если конечно функция не возвращает сами входные значения, не меняя их, в качестве своего результата выполнения. ps: min здесь бессмыслен, Вы группируете по полю DateTimeCatched и по нему же ищете min. результатом min тогда будет само значение поля DateTimeCatched ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2008, 17:15 |
|
||
|
Неоптимальное использование WHERE в VIEW
|
|||
|---|---|---|---|
|
#18+
Ёшps: min здесь бессмыслен, Вы группируете по полю DateTimeCatched и по нему же ищете min. результатом min тогда будет само значение поля DateTimeCatched+1 GROUP BY в этом случае получается эквивалентным DISTINCT. а может и DISTINCT не нужен? если например комбинация ("SampleID", "DateTimeCatched", "SigID", "DateTimeAdded") уникальна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2008, 17:46 |
|
||
|
Неоптимальное использование WHERE в VIEW
|
|||
|---|---|---|---|
|
#18+
ааа.. да, там ошибка, в group by этого поля не должно быть. Но все равно непонятно, почему планировщик не видит, что результат выполнения функции (min) это и есть значение поля таблицы и не исполняет как будто where задан внутри. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2008, 18:16 |
|
||
|
Неоптимальное использование WHERE в VIEW
|
|||
|---|---|---|---|
|
#18+
Robert Ayrapetyan wrote: > CREATE OR REPLACE VIEW view_name AS > SELECT "SampleID", min("DateTimeCatched") as "min", "SigID", > "DateTimeAdded", "DateTimeAdded" - "DateTimeCatched" as "InternalDuration" > FROM "sigs" > JOIN "samples" USING ("SigID") > JOIN "radar" USING ("SampleID") > WHERE "DateTimeAdded" >= "DateTimeCatched" > GROUP BY "SampleID", "DateTimeCatched", "SigID", "DateTimeAdded"; У вас очень странный агрегирующий запрос. Поле "DateTimeCatched" у вас и агрегируется, и не агрегируется. (в GROUP BY находится). Вы уж там как-то определитесь. Либо агрегируете его, либо - нет. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2008, 00:11 |
|
||
|
Неоптимальное использование WHERE в VIEW
|
|||
|---|---|---|---|
|
#18+
С "DateTimeCatched" понятно, ошибка вышла. VIEW выглядит так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. Вопрос был не в том где ошибка, а почему view ... where работает намного медленнее, чем where внутри view, хотя используется один и тот же источник - значение колонки в таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2008, 11:06 |
|
||
|
Неоптимальное использование WHERE в VIEW
|
|||
|---|---|---|---|
|
#18+
Robert Ayrapetyan wrote: > CREATE OR REPLACE VIEW view_name AS > SELECT "SampleID", min("DateTimeCatched") as "min", "SigID", > "DateTimeAdded", "DateTimeAdded" - "DateTimeCatched" as "InternalDuration" > FROM "sigs" > JOIN "samples" USING ("SigID") > JOIN "radar" USING ("SampleID") > WHERE "DateTimeAdded" >= "DateTimeCatched" > GROUP BY "SampleID", "SigID", "DateTimeAdded"; На самом деле ничего не изменилось, запрос правильнее не стал. у вас всё еще есть это поле "DateTimeCatched" в выражении "DateTimeAdded" - "DateTimeCatched" as "InternalDuration" Т.е. и в агрегате, и вне агрегата, но вы теперь еще по нему и не группируете, что уже совсем плохо. Я не знаю как в PG, но в некоторых серверах такие запросы вообще не работают, вызывают семантическую ошибку. Так что уж определяйтесь, либо вы агрегируете это поле, либо нет. Третьего не дано. > Вопрос был не в том где ошибка, а почему view ... where работает намного > медленнее, чем where внутри view, хотя используется один и тот же > источник - значение колонки в таблице. Сначала надо иметь правильный запрос, а потом уже - быстро работающий. Быстро работающий неправильный запрос никому не нужен. К тому же неправильный запрос очень большой шанс имеет быть также и небыстрым. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2008, 11:45 |
|
||
|
Неоптимальное использование WHERE в VIEW
|
|||
|---|---|---|---|
|
#18+
Robert Ayrapetyanааа.. да, там ошибка, в group by этого поля не должно быть. Но все равно непонятно, почему планировщик не видит, что результат выполнения функции (min) это и есть значение поля таблицы и не исполняет как будто where задан внутри.потому что в общем случае результат функции можно узнать только выполнив запрос. конкретно с min - об этом можно догадаться но такую оптимизацию никто не делал потому что так min никто не использует. imho :) если Вы сделаете фильтр по колонке, а не агрегатной функции - то Вы увидите как это условие попадёт внутрь view в его where - как вы и хотели. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2008, 11:52 |
|
||
|
Неоптимальное использование WHERE в VIEW
|
|||
|---|---|---|---|
|
#18+
MasterZivЯ не знаю как в PG, но в некоторых серверах такие запросы вообще не работают, вызывают семантическую ошибку. Так что уж определяйтесь, либо вы агрегируете это поле, либо нет. Третьего не дано.угу, они не должны работать. по стандарту SQL, если я не ошибаюсь. PG на такой запрос скажет: Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2008, 12:01 |
|
||
|
Неоптимальное использование WHERE в VIEW
|
|||
|---|---|---|---|
|
#18+
На самом деле сейчас запрос выглядит вот так (в виде функции): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. И работает быстро. Но как, еще раз повторюсь, вытащить Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2008, 13:48 |
|
||
|
Неоптимальное использование WHERE в VIEW
|
|||
|---|---|---|---|
|
#18+
Robert AyrapetyanНа самом деле сейчас запрос выглядит вот так (в виде функции): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. И работает быстро. Но как, еще раз повторюсь, вытащить Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2008, 14:58 |
|
||
|
Неоптимальное использование WHERE в VIEW
|
|||
|---|---|---|---|
|
#18+
В виде функции значит CREATE FUNCTION.... (DateTimeFrom, DateTimeTo) Как в последнем сообщении. А наружу, значит то же самое, но SELECT ... FROM view... WHERE SigDateTimeAdded BETWEEN ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2008, 13:55 |
|
||
|
Неоптимальное использование WHERE в VIEW
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. так чего вы хотите? непонятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2008, 14:31 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=35509076&tid=2004098]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
54ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 224ms |
| total: | 375ms |

| 0 / 0 |
