ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Странное план ИМХО.
25 сообщений из 34, страница 1 из 2
  1  все
Странное план ИМХО.
    #38724294
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold_
Гость
Всем привет.

Странное поведение ИМХО.
сделал:
Код: sql
1.
ANALYZE sessions;



выполняю запрос:
Код: sql
1.
2.
3.
SELECT min(s.id) FROM  sessions s
				WHERE  s.start_datetime >= '2014-08-01 00:00'
				   AND s.start_datetime <  '2014-08-01 00:50'


такой план:
Код: sql
1.
2.
3.
Aggregate  (cost=5700.13..5700.14 rows=1 width=4)
  ->  Index Scan using i_sessions_start_datetime on sessions s  (cost=0.00..5694.61 rows=2207 width=4)
        Index Cond: ((start_datetime >= '2014-08-01 00:00:00+00'::timestamp with time zone) AND (start_datetime < '2014-08-01 00:50:00+00'::timestamp with time zone))



незначительно меняю запрос:
Код: sql
1.
2.
3.
SELECT min(s.id) FROM  sessions s
				WHERE  s.start_datetime >= '2014-08-01 00:00'
				   AND s.start_datetime <  '2014-08-01 00:55'



теперь такой план:
Код: sql
1.
2.
3.
4.
5.
6.
Result  (cost=5891.67..5891.68 rows=1 width=0)
  InitPlan 1 (returns $0)
    ->  Limit  (cost=0.00..5891.67 rows=1 width=4)
          ->  Index Scan using sessions_pkey on sessions s  (cost=0.00..14299094.11 rows=2427 width=4)
                Index Cond: (id IS NOT NULL)
                Filter: ((start_datetime >= '2014-08-01 00:00:00+00'::timestamp with time zone) AND (start_datetime < '2014-08-01 00:55:00+00'::timestamp with time zone))



как сделать чтобы и во втором запросе был план как в первом?
...
Рейтинг: 0 / 0
20.08.2014, 12:05:16
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38724301
--поправил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
--поправил
Гость
Gold_,
для начала привести реальный 2-й запрос, а то как-то не того-этого
...
Рейтинг: 0 / 0
20.08.2014, 12:09:53
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38724453
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold_
Гость
--поправил,

разница в пять минут
s.start_datetime < '2014-08-01 00:55'
...
Рейтинг: 0 / 0
20.08.2014, 13:33:08
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38724529
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
Gold_,

А можно вывод
Код: sql
1.
EXPLAIN (analyze, buffers)

глянуть, на оба варианта?
...
Рейтинг: 0 / 0
20.08.2014, 14:17:05
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38724593
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold_
Гость
vyegorov,

первый
Код: sql
1.
2.
3.
4.
5.
6.
Aggregate  (cost=5353.89..5353.90 rows=1 width=4) (actual time=1444.206..1444.206 rows=1 loops=1)
  Buffers: shared hit=106 read=276
  ->  Index Scan using i_sessions_start_datetime on sessions s  (cost=0.00..5348.70 rows=2076 width=4) (actual time=155.701..1443.796 rows=2047 loops=1)
        Index Cond: ((start_datetime >= '2014-08-01 00:00:00+00'::timestamp with time zone) AND (start_datetime < '2014-08-01 00:50:00+00'::timestamp with time zone))
        Buffers: shared hit=106 read=276
Total runtime: 1444.281 ms



Код: sql
1.
2.
3.
SELECT min(s.id) FROM  sessions s
				WHERE  s.start_datetime >= '2014-08-01 00:00'
				   AND s.start_datetime <  '2014-08-01 00:55'


стал работать "правильно"
смещаю еще на пять минут

Код: sql
1.
2.
3.
 SELECT min(s.id) FROM  sessions s
				WHERE  s.start_datetime >= '2014-08-01 00:00'
				   AND s.start_datetime <  '2014-08-01 01:00'



не могу дождаться выполнения
(
...
Рейтинг: 0 / 0
20.08.2014, 14:59:28
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38724641
--поправил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
--поправил
Гость
Gold_,

SELECT count(1) FROM session; ?

ЗЫ сделайте CTE выборку по времени, а только от него -- агрегат. Будет аналогично 1-му всегда
...
Рейтинг: 0 / 0
20.08.2014, 15:24:15
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38724741
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold_
Гость
--поправилGold_,

SELECT count(1) FROM session; ?

ЗЫ сделайте CTE выборку по времени, а только от него -- агрегат. Будет аналогично 1-му всегда

122860475

спасибо! так и сделаю.
...
Рейтинг: 0 / 0
20.08.2014, 16:16:55
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38725234
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold_
Гость
Сделал. Но вопрос остался. Почему выбирался такой план?

"PostgreSQL 9.2.4 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit"
...
Рейтинг: 0 / 0
21.08.2014, 10:01:57
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38725267
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
Gold_Сделал. Но вопрос остался. Почему выбирался такой план?

Я полагаю, что в таблицу данные прибывают резвенько, а с настройками по умолчанию для больших таблиц `autvacuum` приходит все реже. Вот база и посчитала, что ей будет выгоднее пойти по индексу `sessions_pkey`.
Связано может быть с тем, что на момент запроса гистограмма показала ожидание по записям существенно выше реального.

Рекомендую сделать так
Код: sql
1.
2.
3.
ALTER TABLE sessions ALTER start_datetime SET STATISTICS 500;
ALTER TABLE sessions SET (autovacuum_analyze_scale_factor=0.02);
VACUUM ANALYZE sessions;


Это увеличит размер гистограммы для колонки `start_datetime` и заставит систему анализировать таблицу чаще. Должно стать лучше.

Gold_"PostgreSQL 9.2.4 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit"

Надо до 9.2.9 апгрейднутся, дырки были.
...
Рейтинг: 0 / 0
21.08.2014, 10:36:06
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38725492
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold_
Гость
vyegorov,

спасибо - попробую!
...
Рейтинг: 0 / 0
21.08.2014, 12:51:27
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38725505
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold_
Гость
vyegorov,
Вообще перед стартом топика пробовал так:
Код: sql
1.
2.
ALTER TABLE sessions ALTER start_datetime SET STATISTICS 10000;
VACUUM ANALYZE sessions;



не помогло.

сейчас проверю еще раз.
...
Рейтинг: 0 / 0
21.08.2014, 13:02:38
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38725601
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
Gold_
Код: sql
1.
2.
ALTER TABLE sessions ALTER start_datetime SET STATISTICS 10000;
VACUUM ANALYZE sessions;


Как по мне — 10000 много слишком.

А вы могли бы подобрать такие значения `start_datetime`, чтобы повторить начальную ситуацию и запостить
`EXPLAIN (analyze, buffers)` работающего диапазона

`EXPLAIN` “бесконечного” диапазона

`EXPLAIN (analyze, buffers)` для “бесконечного” диапазона с CTE

Хочется глянуть на ожидания и реальные цифры.

А индекс на `(strat_datetime,id)` рассматривался?
...
Рейтинг: 0 / 0
21.08.2014, 14:14:14
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38725653
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold_
Гость
vyegorov,
`EXPLAIN (analyze, buffers)` работающего диапазона

Код: sql
1.
2.
3.
SELECT min(s.id) FROM  sessions s
				WHERE  s.start_datetime >= '2014-08-01 00:00'
				   AND s.start_datetime <  '2014-08-01 00:55'



Код: plaintext
1.
2.
3.
4.
5.
6.
Aggregate  (cost=5890.60..5890.61 rows=1 width=4) (actual time=2.629..2.629 rows=1 loops=1)
  Buffers: shared hit=405
  ->  Index Scan using i_sessions_start_datetime on sessions s  (cost=0.00..5884.89 rows=2284 width=4) (actual time=0.088..2.352 rows=2279 loops=1)
        Index Cond: ((start_datetime >= '2014-08-01 00:00:00+00'::timestamp with time zone) AND (start_datetime < '2014-08-01 00:55:00+00'::timestamp with time zone))
        Buffers: shared hit=405
Total runtime: 2.688 ms

`EXPLAIN` “бесконечного” диапазона

Код: sql
1.
2.
3.
SELECT min(s.id) FROM  sessions s
				WHERE  s.start_datetime >= '2014-08-01 00:00'
				   AND s.start_datetime <  '2014-08-01 01:00'



Код: plaintext
1.
2.
3.
4.
5.
6.
Result  (cost=5744.94..5744.95 rows=1 width=0)
  InitPlan 1 (returns $0)
    ->  Limit  (cost=0.00..5744.94 rows=1 width=4)
          ->  Index Scan using sessions_pkey on sessions s  (cost=0.00..14310657.98 rows=2491 width=4)
                Index Cond: (id IS NOT NULL)
                Filter: ((start_datetime >= '2014-08-01 00:00:00+00'::timestamp with time zone) AND (start_datetime < '2014-08-01 01:00:00+00'::timestamp with time zone))


`EXPLAIN (analyze, buffers)` для “бесконечного” диапазона с CTE

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
with ids
as
(SELECT s.id FROM  sessions s
				WHERE  s.start_datetime >= '2014-08-01 00:00'
				   AND s.start_datetime <  '2014-08-01 01:00'
)

SELECT 	min(id) FROM ids




Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
Aggregate  (cost=6470.39..6470.40 rows=1 width=4) (actual time=81.623..81.623 rows=1 loops=1)
  Buffers: shared hit=409 read=7
  CTE ids
    ->  Index Scan using i_sessions_start_datetime on sessions s  (cost=0.00..6414.34 rows=2491 width=4) (actual time=0.034..80.546 rows=2450 loops=1)
          Index Cond: ((start_datetime >= '2014-08-01 00:00:00+00'::timestamp with time zone) AND (start_datetime < '2014-08-01 01:00:00+00'::timestamp with time zone))
          Buffers: shared hit=409 read=7
  ->  CTE Scan on ids  (cost=0.00..49.82 rows=2491 width=4) (actual time=0.043..81.289 rows=2450 loops=1)
        Buffers: shared hit=409 read=7
Total runtime: 81.694 ms
...
Рейтинг: 0 / 0
21.08.2014, 14:45:40
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38725700
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Durak
Участник
sessions_pkey это индекс на id ???

ну так у тебя там min(s.id) стоит. Это сбивает оптимизатор, понятно почему, никакая статистика тут не поможет.
Ибо в ней нет данных о том как быстро при проходе по индексу по id от меньшего к большему мы попадем на запись в нужном интервале дат!!

запрос вида:
SELECT count(s.id) FROM sessions s
WHERE s.start_datetime >= '2014-08-01 00:00'
AND s.start_datetime < '2014-08-01 00:55'

будет работать всегда по быстрому плану.

так что попробуйте
SELECT count(s.id),min(s.id) FROM sessions s
WHERE s.start_datetime >= '2014-08-01 00:00'
AND s.start_datetime < '2014-08-01 00:55'
...
Рейтинг: 0 / 0
21.08.2014, 15:22:41
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38725727
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
Gold_,

Ожидания совпадают. Не могу сказать почему оптимизатор решает, что пройти по `session_pkey` с фильтром ему будет дешевле.
Попробуйте обновиться.

Если возможно — поделитесь снимком таблички? Или хотя бы описанием ее (`\d sessions` в psql) и выводом запроса:
Код: sql
1.
select count(1),min(start_datetime),max(start_datetime) from sessions;
...
Рейтинг: 0 / 0
21.08.2014, 15:41:54
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38725738
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
Ivan Duraksessions_pkey это индекс на id ???

ну так у тебя там min(s.id) стоит. Это сбивает оптимизатор, понятно почему, никакая статистика тут не поможет.
Ибо в ней нет данных о том как быстро при проходе по индексу по id от меньшего к большему мы попадем на запись в нужном интервале дат!!

А я не понимаю. С моей точки зрения оптимизатор должен быть пессимистичен и оценивать проход по `sessions_pkey` как проход по всему индексу с фильтрацией. Что должно быть явно дороже прохода по части другого индекса.

Я потому и прошу снимок таблицы, чтобы побаловаться, индексы подропать…
...
Рейтинг: 0 / 0
21.08.2014, 15:49:08
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38725746
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold_
Гость
Ivan Duraksessions_pkey это индекс на id ???

ну так у тебя там min(s.id) стоит. Это сбивает оптимизатор, понятно почему, никакая статистика тут не поможет.
Ибо в ней нет данных о том как быстро при проходе по индексу по id от меньшего к большему мы попадем на запись в нужном интервале дат!!

запрос вида:
SELECT count(s.id) FROM sessions s
WHERE s.start_datetime >= '2014-08-01 00:00'
AND s.start_datetime < '2014-08-01 00:55'

будет работать всегда по быстрому плану.

так что попробуйте
SELECT count(s.id),min(s.id) FROM sessions s
WHERE s.start_datetime >= '2014-08-01 00:00'
AND s.start_datetime < '2014-08-01 00:55'

Ivan Durak,
"sessions_pkey это индекс на id ?" Да

Да работает, но это скорее похоже на CTE

Объяснение не понял.
...
Рейтинг: 0 / 0
21.08.2014, 15:52:32
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38726032
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Durak
Участник
vyegorovIvan Duraksessions_pkey это индекс на id ???

ну так у тебя там min(s.id) стоит. Это сбивает оптимизатор, понятно почему, никакая статистика тут не поможет.
Ибо в ней нет данных о том как быстро при проходе по индексу по id от меньшего к большему мы попадем на запись в нужном интервале дат!!

А я не понимаю. С моей точки зрения оптимизатор должен быть пессимистичен и оценивать проход по `sessions_pkey` как проход по всему индексу с фильтрацией. Что должно быть явно дороже прохода по части другого индекса.

Я потому и прошу снимок таблицы, чтобы побаловаться, индексы подропать…
он не пессеместичен. Он оптимизирован!
Ведь для вычисления min(id) и ежу понятно что проще взять поиском одну запись в индексе, а не сканить всё. Но у тебя не просто одна запись минимальная, а еще фильтр. Представь себе теперь что твой фильтр по датам покрывает весь диапазон в таблице. Какой план теперь оптимален?? Ответ - взять по индексу sessions_pkey первую запись! И тут все дело в распределении. Как распределятся даты относительно id. Такой информации нету в статистике. И он угадывает по принципу (если в фильтре по датам выбирается 1% таблицы, значит перебор последовательных id примерно к 100-й записи даст нам одну подпадающую под фильтр) Все, профит
...
Рейтинг: 0 / 0
21.08.2014, 19:43:32
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38726055
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
Ivan Durakон не пессеместичен. Он оптимизирован!
Ведь для вычисления min(id) и ежу понятно что проще взять поиском одну запись в индексе, а не сканить всё. Но у тебя не просто одна запись минимальная, а еще фильтр. Представь себе теперь что твой фильтр по датам покрывает весь диапазон в таблице. Какой план теперь оптимален?? Ответ - взять по индексу sessions_pkey первую запись! И тут все дело в распределении. Как распределятся даты относительно id. Такой информации нету в статистике. И он угадывает по принципу (если в фильтре по датам выбирается 1% таблицы, значит перебор последовательных id примерно к 100-й записи даст нам одну подпадающую под фильтр) Все, профит

Спасибо!
...
Рейтинг: 0 / 0
21.08.2014, 20:36:39
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38726073
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold_
Гость
vyegorovIvan Duraksessions_pkey это индекс на id ???

ну так у тебя там min(s.id) стоит. Это сбивает оптимизатор, понятно почему, никакая статистика тут не поможет.
Ибо в ней нет данных о том как быстро при проходе по индексу по id от меньшего к большему мы попадем на запись в нужном интервале дат!!

А я не понимаю. С моей точки зрения оптимизатор должен быть пессимистичен и оценивать проход по `sessions_pkey` как проход по всему индексу с фильтрацией. Что должно быть явно дороже прохода по части другого индекса.

Я потому и прошу снимок таблицы, чтобы побаловаться, индексы подропать…

надо уточнить у руководство. еще интересно?
...
Рейтинг: 0 / 0
21.08.2014, 21:08:54
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38726090
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold_
Гость
Ivan Durakvyegorovпропущено...


А я не понимаю. С моей точки зрения оптимизатор должен быть пессимистичен и оценивать проход по `sessions_pkey` как проход по всему индексу с фильтрацией. Что должно быть явно дороже прохода по части другого индекса.

Я потому и прошу снимок таблицы, чтобы побаловаться, индексы подропать…
он не пессеместичен. Он оптимизирован!
Ведь для вычисления min(id) и ежу понятно что проще взять поиском одну запись в индексе, а не сканить всё. Но у тебя не просто одна запись минимальная, а еще фильтр. Представь себе теперь что твой фильтр по датам покрывает весь диапазон в таблице. Какой план теперь оптимален?? Ответ - взять по индексу sessions_pkey первую запись! И тут все дело в распределении. Как распределятся даты относительно id. Такой информации нету в статистике. И он угадывает по принципу (если в фильтре по датам выбирается 1% таблицы, значит перебор последовательных id примерно к 100-й записи даст нам одну подпадающую под фильтр) Все, профит

Объяснение в принципе понятно, но про процент не очень.
Перефразирую Вас (как я понял)

И он угадывает по принципу (если в фильтре по датам выбирается 1% таблицы, значит перебор последовательных id после 1% записей даст нам одну подпадающую под фильтр)

правильно?
Тогда вопросы по плану:
Код: plaintext
1.
2.
3.
4.
5.
6.
Result  (cost=5744.94..5744.95 rows=1 width=0)
  InitPlan 1 (returns $0)
    ->  Limit  (cost=0.00..5744.94 rows=1 width=4)
          ->  Index Scan using sessions_pkey on sessions s  (cost=0.00..14310657.98 rows=2491 width=4)
                Index Cond: (id IS NOT NULL)
                Filter: ((start_datetime >= '2014-08-01 00:00:00+00'::timestamp with time zone) AND (start_datetime < '2014-08-01 01:00:00+00'::timestamp with time zone))

стоимость 14310657.98 - это стоимость поднятие индекса целиком?
но 2491 записи оптимизатор, думает что найдет подходящий запись?

Тогда процент перехода примерно 0,04 процента (5744.95/14310657.98*100)


Но, тогда нет объяснение, как запрос работал месяц назад - от общего количества процент был меньше, а план был "правильным"
...
Рейтинг: 0 / 0
21.08.2014, 21:50:22
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38726100
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold_
Гость
Ivan Durakvyegorovпропущено...


А я не понимаю. С моей точки зрения оптимизатор должен быть пессимистичен и оценивать проход по `sessions_pkey` как проход по всему индексу с фильтрацией. Что должно быть явно дороже прохода по части другого индекса.

Я потому и прошу снимок таблицы, чтобы побаловаться, индексы подропать…
он не пессеместичен. Он оптимизирован!
Ведь для вычисления min(id) и ежу понятно что проще взять поиском одну запись в индексе, а не сканить всё. Но у тебя не просто одна запись минимальная, а еще фильтр. Представь себе теперь что твой фильтр по датам покрывает весь диапазон в таблице. Какой план теперь оптимален?? Ответ - взять по индексу sessions_pkey первую запись! И тут все дело в распределении. Как распределятся даты относительно id. Такой информации нету в статистике. И он угадывает по принципу (если в фильтре по датам выбирается 1% таблицы, значит перебор последовательных id примерно к 100-й записи даст нам одну подпадающую под фильтр) Все, профит

да, Вы правы

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
create table test_ses
as
SELECT id, TIMESTAMP WITH TIME ZONE 'epoch' +random()*(1*60*60*24*365)* INTERVAL '1 second' as start_datetime FROM  generate_series(1,1000000) t(id);
ALTER TABLE test_ses  ADD CONSTRAINT test_ses_pkey PRIMARY KEY(id);
CREATE INDEX test_ses_start_datetime
  ON test_ses
  USING btree
  (start_datetime);
ANALYZE test_ses;




Код: sql
1.
2.
3.
SELECT min(s.id) FROM  test_ses s
				WHERE  s.start_datetime >= '1970-08-01 00:00'
				   AND s.start_datetime <  '1970-08-10 00:00'



Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Result  (cost=1.59..1.60 rows=1 width=0) (actual time=0.072..0.072 rows=1 loops=1)
  Buffers: shared hit=1 read=3
  InitPlan 1 (returns $0)
    ->  Limit  (cost=0.00..1.59 rows=1 width=4) (actual time=0.069..0.070 rows=1 loops=1)
          Buffers: shared hit=1 read=3
          ->  Index Scan using test_ses_pkey on test_ses s  (cost=0.00..38889.36 rows=24450 width=4) (actual time=0.068..0.068 rows=1 loops=1)
                Index Cond: (id IS NOT NULL)
                Filter: ((start_datetime >= '1970-08-01 00:00:00+00'::timestamp with time zone) AND (start_datetime < '1970-08-10 00:00:00+00'::timestamp with time zone))
                Rows Removed by Filter: 14
                Buffers: shared hit=1 read=3
Total runtime: 0.093 ms

SELECT 1.58/38889.36*100

0.004062807924841139067300

только процент меньший, но и условия другие
...
Рейтинг: 0 / 0
21.08.2014, 22:22:15
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38726110
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
Gold_надо уточнить у руководство. еще интересно?
Нет, спасибо. Уточните, пожалуйста, за сколько месяцев у вас там данные?
...
Рейтинг: 0 / 0
21.08.2014, 22:53:51
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38726112
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold_
Гость
vyegorovGold_надо уточнить у руководство. еще интересно?
Нет, спасибо. Уточните, пожалуйста, за сколько месяцев у вас там данные?

в этой таблице с 2012 года
...
Рейтинг: 0 / 0
21.08.2014, 23:02:24
| Ответить | Цитировать | Написать  
Странное план ИМХО.
    #38726185
йокарный бабай
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
йокарный бабай
Гость
Ivan Durakvyegorovпропущено...


А я не понимаю. С моей точки зрения оптимизатор должен быть пессимистичен и оценивать проход по `sessions_pkey` как проход по всему индексу с фильтрацией. Что должно быть явно дороже прохода по части другого индекса.

Я потому и прошу снимок таблицы, чтобы побаловаться, индексы подропать…
он не пессеместичен. Он оптимизирован!
Ведь для вычисления min(id) и ежу понятно что проще взять поиском одну запись в индексе, а не сканить всё. Но у тебя не просто одна запись минимальная, а еще фильтр. Представь себе теперь что твой фильтр по датам покрывает весь диапазон в таблице. Какой план теперь оптимален?? Ответ - взять по индексу sessions_pkey первую запись! И тут все дело в распределении. Как распределятся даты относительно id. Такой информации нету в статистике. И он угадывает по принципу (если в фильтре по датам выбирается 1% таблицы, значит перебор последовательных id примерно к 100-й записи даст нам одну подпадающую под фильтр) Все, профит

нахер-нахер такую оптимизацию

PS предположение о полной независимости распределения временных отсечек и id -- крайне редко выполняется. часто оно почти монотонно. т.е. последний процент дат будет лежать рядом с последним процентом id


надеюсь таки в "пописать оптимайзер" таких долбо..бов за профитом не пускают
...
Рейтинг: 0 / 0
22.08.2014, 03:57:29
| Ответить | Цитировать | Написать  
25 сообщений из 34, страница 1 из 2
  1  все
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Странное план ИМХО.
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=53&fpage=124&tid=1998522]:
 0ms
get settings:
 4ms
get forum list:
 13ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 265ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 44ms
get tp. blocked users:
 1ms
others: 191ms
total:  533ms
созд. / загр.: 533ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]