Thread: вариации выполнения запроса

Доброго всем.

В общем речь не о проблеме, а так, может кто обсудит такой случай с
запросом. Сам пока не разобрался.

1.
select ...
from ...
where ...
    and xyz.abc ~ 'а' -- кирилическая буква
;
Результат:
------------------------
1601 запис(ь/и/ей)

Время выполнения: 1,420.021 мсек



2. Теперь совершенно тот же запрос, но
where ...
    and xyz.abc ~ 'и' -- кирилическая буква
;
Результат:
------------------------
1140 запис(ь/и/ей)

Время выполнения: 910.013 мсек


3. Теперь совершенно тот же запрос, но
where ...
    and xyz.abc ~ 'щ' -- кирилическая буква
;
Результат:
------------------------
150 запис(ь/и/ей)

Время выполнения: 1,260.019 мсек


Пояснение. Три запуска одного запроса с разными буквами - существенно
различается соотношение количества строк к времени выполнения.

С чем это может быть связано?

--
---
С уважением,
Михаил Наседкин

On 10/29/10 14:02, Mihail Nasedkin wrote:
> Пояснение. Три запуска одного запроса с разными буквами - существенно
> различается соотношение количества строк к времени выполнения.
>
> С чем это может быть связано?
А план запроса посмотреть не пришло в голову? Что там написано?
Подозреваю, что SeqScan. Причём, в таблице сильно больше записей, чем в
результате запроса.

29.10.10, Dmitriy Igrishin<dmitigr@gmail.com> написал(а):
> Добрый день, Михаил
>
> Рекомендую начать с этого:
> http://www.postgresql.org/docs/9.0/static/sql-explain.html
>

Неужели план существенно меняется из-за одной буквы в критерии?
Оптимизатор ловчит?

Пока разбираться со сложным планом не стал.

--
---
С уважением,
Михаил Наседкин

Привет,

2010/10/29 Mihail Nasedkin <m.nasedkin@gmail.com>:
> Пояснение. Три запуска одного запроса с разными буквами - существенно
> различается соотношение количества строк к времени выполнения.
>
> С чем это может быть связано?

На время выполнения в основном влияет кол-во записей, по которым
ведётся поиск, а не кол-во найденных записей.

>
> --
> ---
> С уважением,
> Михаил Наседкин
>
> --
> Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-ru-general
>



--
Sergey Konoplev

Blog: http://gray-hemp.blogspot.com /
Linkedin: http://ru.linkedin.com/in/grayhemp /
JID/GTalk: gray.ru@gmail.com / Skype: gray-hemp

29.10.10, Andrey N. Oktyabrski<ano@bestmx.ru> написал(а):
> On 10/29/10 14:02, Mihail Nasedkin wrote:
>> Пояснение. Три запуска одного запроса с разными буквами - существенно
>> различается соотношение количества строк к времени выполнения.
>>
>> С чем это может быть связано?
> А план запроса посмотреть не пришло в голову? Что там написано?
> Подозреваю, что SeqScan. Причём, в таблице сильно больше записей, чем в
> результате запроса.
>

Вы полностью правы - гораздо сильно больше.

--
---
С уважением,
Михаил Наседкин

29.10.10, Sergey Konoplev<gray.ru@gmail.com> написал(а):
> Привет,

>
> На время выполнения в основном влияет кол-во записей, по которым
> ведётся поиск, а не кол-во найденных записей.
>

Поиск во всех трех вариантах ведется по одинаковому количеству записей.

--
---
С уважением,
Михаил Наседкин

2010/10/29 Mihail Nasedkin <m.nasedkin@gmail.com>:
> 29.10.10, Sergey Konoplev<gray.ru@gmail.com> написал(а):
>> Привет,
>
>>
>> На время выполнения в основном влияет кол-во записей, по которым
>> ведётся поиск, а не кол-во найденных записей.
>>
>
> Поиск во всех трех вариантах ведется по одинаковому количеству записей.

В этом и дело.

>
> --
> ---
> С уважением,
> Михаил Наседкин
>



--
Sergey Konoplev

Blog: http://gray-hemp.blogspot.com /
Linkedin: http://ru.linkedin.com/in/grayhemp /
JID/GTalk: gray.ru@gmail.com / Skype: gray-hemp

29.10.10, Sergey Konoplev<gray.ru@gmail.com> написал(а):
> 2010/10/29 Mihail Nasedkin <m.nasedkin@gmail.com>:
>> 29.10.10, Sergey Konoplev<gray.ru@gmail.com> написал(а):
>>> Привет,
>>
>>>
>>> На время выполнения в основном влияет кол-во записей, по которым
>>> ведётся поиск, а не кол-во найденных записей.
>>>
>>
>> Поиск во всех трех вариантах ведется по одинаковому количеству записей.
>
> В этом и дело.
>

Так как же? Вы утвердили, что результат зависит ..., я утвердил, что
запрос полностью идентичен, поле и таблица поиска таже и не менялась
между запросами, количество строк одинаково. Теперь вы подтверждаете
мое утверждение, тем самым противоречя первому своему утверждению.


--
---
С уважением,
Михаил Наседкин

Все же глянул план - полностью идентичен во всех трех вариантах!

--
---
С уважением,
Михаил Наседкин

Что меня мучает - чем одна буква "лучше" другой в запросе по колонке текста.

29.10.10, Mihail Nasedkin<m.nasedkin@gmail.com> написал(а):
> Все же глянул план - полностью идентичен во всех трех вариантах!
>
> --
> ---
> С уважением,
> Михаил Наседкин
>


--
---
С уважением,
Михаил Наседкин

2010/10/29 Mihail Nasedkin <m.nasedkin@gmail.com>:
> Все же глянул план - полностью идентичен во всех трех вариантах!

Хорошо, давайте упростим задачу. Есть массив из 100 элементов, 97 букв
"а" и 3 буквы "и". Чтобы найти буквы "а" надо пройти по всему массиву,
чтобы найти буквы "и" надо тоже пройти по всему массиву. Кол-во
итераций одинаковое в обоих случаях не смотря на то, что букв "а" 97,
а "и" всего 3.

>
> --
> ---
> С уважением,
> Михаил Наседкин
>
> --
> Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-ru-general
>



--
Sergey Konoplev

Blog: http://gray-hemp.blogspot.com /
Linkedin: http://ru.linkedin.com/in/grayhemp /
JID/GTalk: gray.ru@gmail.com / Skype: gray-hemp

Еще смотрю, что селективность буквы 'щ' выше в простом запросе на одну
таблицу, чем буквы 'и', что естественно для нормального текста:

88 запис(ь/и/ей)
Время выполнения: 10.000 мсек

Против

2348 запис(ь/и/ей)
Время выполнения: 600.009 мсек

Не разобрался :( ....

--
---
С уважением,
Михаил Наседкин

29.10.10, Dmitriy Igrishin<dmitigr@gmail.com> написал(а):
> Михаил,
>
> А Вы запустите тестовый сценарий, который выполнит для каждой искомой
> буквы не под одному запросу, а скажем, по 100, и сосчитайте среднее время.
> Полагаю, что оно будет примерно одинаковым, если происходит перебор
> всех записей таблицы.

Я уже 1000 раз запустил, естественно все записи на seqscan.
Результат стабильный.

Куда еще? Повторяю - это не проблема, но хотелось докопаться.

Всем промежуточное спасибо.

--
---
С уважением,
Михаил Наседкин

On 10/29/10 14:14, Mihail Nasedkin wrote:
> 29.10.10, Andrey N. Oktyabrski<ano@bestmx.ru>  написал(а):
>> On 10/29/10 14:02, Mihail Nasedkin wrote:
>>> Пояснение. Три запуска одного запроса с разными буквами - существенно
>>> различается соотношение количества строк к времени выполнения.
>>> С чем это может быть связано?
>> А план запроса посмотреть не пришло в голову? Что там написано?
>> Подозреваю, что SeqScan. Причём, в таблице сильно больше записей, чем в
>> результате запроса.
> Вы полностью правы - гораздо сильно больше.
Поэтому количество найденных записей не сильно влияет на время выдачи
результата.

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

--
---
С уважением,
Михаил Наседкин

29.10.10, Dmitriy Igrishin<dmitigr@gmail.com> написал(а):
> Поясните, Вы запустили 3000 запросов (по 1000 на каждую из 3-х букв),
> потом вычислили суммарное время выполнения каждой тысячи запросов,
> разделили эти три суммы на 1000 по отдельности, и, очевиден сильный
> разброс значений?
>

Нет пока только "~1000" всего на три. Мне этого хватает, не уверен,
что вариация выровняется после 5000...Если Вы настаиваете, придется
сделать.

Твердого знака вообще "не дождался", а его практически нет в записях.


--
---
С уважением,
Михаил Наседкин

Теперь другая незадача - независимые тесты на скорость при тысячных
повторностях.

Опять нерадость...

29.10.10, Mihail Nasedkin<m.nasedkin@gmail.com> написал(а):
> 29.10.10, Dmitriy Igrishin<dmitigr@gmail.com> написал(а):
>> Поясните, Вы запустили 3000 запросов (по 1000 на каждую из 3-х букв),
>> потом вычислили суммарное время выполнения каждой тысячи запросов,
>> разделили эти три суммы на 1000 по отдельности, и, очевиден сильный
>> разброс значений?
>>
>
> Нет пока только "~1000" всего на три. Мне этого хватает, не уверен,
> что вариация выровняется после 5000...Если Вы настаиваете, придется
> сделать.
>
> Твердого знака вообще "не дождался", а его практически нет в записях.
>
>
> --
> ---
> С уважением,
> Михаил Наседкин
>


--
---
С уважением,
Михаил Наседкин

On 10/29/10 15:29, Mihail Nasedkin wrote:
> Я же говорю, что сильно влияет, причем в обратную логике сторону.
Разброс максимум в полтора раза, судя по приведённым результатам.

P.S. Вообще, разговор беспредметный, пока не озвучены версия постгреса,
кодировка базы, общее количество записей,
максимальная/минимальная/средняя длина поля и т.п.

Спасибо Дмитрий за конструктивное предложение. Сейчас запустил, но не
для одной таблицы, всеже для конечного запроса.

Что я должен увидеть после запуска? Пока ничего не видно, выполняется...

--
---
С уважением,
Михаил Наседкин

В функции не хватает промежуточного вывода.

--
---
С уважением,
Михаил Наседкин

Здравствуйте, Mihail.

Вы писали 29 октября 2010 г., 15:35:53:

MN> Твердого знака вообще "не дождался", а его практически нет в записях.
ИМХО.. Ключевая фраза! Буковка "а" наверно быстрее всех находится?

Чем быстрее буковка нашлась в поле записи - тем быстрее ясно что запись
попадает в выборку... и до конца смотреть поле не надо.

--
  Сергей

29.10.10, serg-sale<serg-sale@yandex.ru> написал(а):
> Здравствуйте, Mihail.
>
> Вы писали 29 октября 2010 г., 15:35:53:
>
> MN> Твердого знака вообще "не дождался", а его практически нет в записях.
> ИМХО.. Ключевая фраза! Буковка "а" наверно быстрее всех находится?
>
> Чем быстрее буковка нашлась в поле записи - тем быстрее ясно что запись
> попадает в выборку... и до конца смотреть поле не надо.
>
> --
>   Сергей

Похоже на истину. Спасибо большое.


--
---
С уважением,
Михаил Наседкин