Почему это не случайная? Он же их никаким условием не отбирает и не сортирует.CyberMax писал(а):Ну, там у него не случайная первая тысяча, а просто тысяча. Хотя, конечно, сути это не меняет.
select
А что тут страшного-сложного? У меня запросы без секции PLAN только года два как появляться начали... Да и то половина хинтами подрулена.CyberMax писал(а):И что, перед запросом индекс активировать/деактивировать? Или план серверу передавать? Похоже на операцию на глазах через известное место...Merlin писал(а):и инкай-декай её на вставке-удалении триггерами на EJOU. Заглянувши в неё перед запросом, узнаешь, есть ли смысл использовать индекс. Он не только в случае отсутствия записей выигрыш даст.
Ну и как же тогда жить то вообще? У меня одна большая таблица, в ней записи принимают всего три состояния, в любом случаее в конце жизни запись занимает последнее состоянии, это 3. В этом виде она должна дальще существовать, т.е. удалять ее нельзя, она для отчетов нужна.
В таблице записи могут приходить с разными состояниями, с 1, 2, и 3.
Записи полученные с 1 и 2 подвергаются обработке, 1 переходит в 2. а 2 в 3. Записи полученные с состоянием 3 не обрабатываются.
Мне нужно сделать выборку, где в начале должны быть записи с состоянием 1 (если они есть) , затем, если их меньше 1000, получить записи с состоянием 2, ну если в сумме их меньше 1000 добивается записями с состоянием 3.
Каждая из групп записей по состояниям, имеет еще и собственную сортировку, и поэтому их нельзя отсортировать по полю состояния в общем запросе.
Вот такая вот задачка. Я сделал это одной таблицей с полем состояния. Но вот и проблемма вылезла, ведть неизвестно, есть ли в данный момент записи с сотоянием 1 или 2 в таблице. записи с состоянием 3 то всегда есть, с ними никаких проблемм нету.
Может как то подругому спроектировать все это добро?
В таблице записи могут приходить с разными состояниями, с 1, 2, и 3.
Записи полученные с 1 и 2 подвергаются обработке, 1 переходит в 2. а 2 в 3. Записи полученные с состоянием 3 не обрабатываются.
Мне нужно сделать выборку, где в начале должны быть записи с состоянием 1 (если они есть) , затем, если их меньше 1000, получить записи с состоянием 2, ну если в сумме их меньше 1000 добивается записями с состоянием 3.
Каждая из групп записей по состояниям, имеет еще и собственную сортировку, и поэтому их нельзя отсортировать по полю состояния в общем запросе.
Вот такая вот задачка. Я сделал это одной таблицей с полем состояния. Но вот и проблемма вылезла, ведть неизвестно, есть ли в данный момент записи с сотоянием 1 или 2 в таблице. записи с состоянием 3 то всегда есть, с ними никаких проблемм нету.
Может как то подругому спроектировать все это добро?
Отжившие своё записи уносить в бездонный архив и работать припеваючи с оперативной табличкой в пару тыщ записей? А ещё - слышал ли мосье про композитные индексы и их использование при сортировке? Правда разной направленности у сегментов индекса быть не может, так что прокатит не всегда и будет вредной при fetchall.
А кто сказал что записей с состоянием 1 пара тысяч? А веть есть еще и с состоянием 2 их еще может быть сколько угодно.Merlin писал(а):Отжившие своё записи уносить в бездонный архив и работать припеваючи с оперативной табличкой в пару тыщ записей? А ещё - слышал ли мосье про композитные индексы и их использование при сортировке? Правда разной направленности у сегментов индекса быть не может, так что прокатит не всегда и будет вредной при fetchall.
И про индексы я тоже слышал
Слушай, чего ты хочешь, чтоб я за тебя решил задачу неведомой, судя по всему, кривой постановки (эт на тему что дополнительными условиями в where ничо не усечь) и зарплату получил? Надо быстро прошерстить 50 лямов записей, но показать потом только тыщу? Тут на днях поминали литовскую фамилию Обломайтис. Разработчики приложений деньги получают вовсе не за многократное писание стереотипного Select * From OneTable.
Да нет, ты лучше отдохни, не нужно за меня ничего проектировать, если есть желание помочь, то помогай, если нет, отдыхайMerlin писал(а):Слушай, чего ты хочешь, чтоб я за тебя решил задачу неведомой, судя по всему, кривой постановки (эт на тему что дополнительными условиями в where ничо не усечь) и зарплату получил? Надо быстро прошерстить 50 лямов записей, но показать потом только тыщу? Тут на днях поминали литовскую фамилию Обломайтис. Разработчики приложений деньги получают вовсе не за многократное писание стереотипного Select * From OneTable.
С твоей в целом непродуманной структурой можно сделать так:
один индекс по двум полям, полю состояний + по полю которому хочешь сортировать внутри (к примеру, дата поступления).
Дальшечтобы селект задействовал этот индекс, план должен получиться типа PLAN (TABLE1 ORDER TABLE1_IDX1)
PS. И полегче с комментариями. Не в своей тетради пишешь, могут и обидеться.
один индекс по двум полям, полю состояний + по полю которому хочешь сортировать внутри (к примеру, дата поступления).
Дальше
Код: Выделить всё
select first 1000 *
from table1
where DocType=:DocType
order by DocType, DateRecPS. И полегче с комментариями. Не в своей тетради пишешь, могут и обидеться.
Нетактичное поведение признаю. Извиняюсь.
Спасибо "WildSery" при выполнении запроса с указанием порядка сортировки соответствущему порядку полей в индексе и соответветствующей направленности запрос выполняется одинаково быстро как для выборки:
в 50 000 000 - нет искомого значения
в 50 000 000 - 1 искомое значение
в 50 000 000 - 30 000 000 искомых значений
SELECT * FROM EJOU WHERE ejstate = 0
--PLAN (EJOU NATURAL)
ORDER BY ejstate desc, EJOU_ID desc
План
PLAN (EJOU ORDER EJOU_IDX2)
Адаптированный план
PLAN (EJOU ORDER EJOU_IDX2)
------ Performance info ------
Prepare time = 0ms
Execute time = 15ms
Current memory = 1 240 416
Max memory = 50 793 376
Memory buffers = 2 048
Reads from disk to cache = 0
Writes from cache to disk = 6
Fetches from cache = 376
Спасибо "WildSery" при выполнении запроса с указанием порядка сортировки соответствущему порядку полей в индексе и соответветствующей направленности запрос выполняется одинаково быстро как для выборки:
в 50 000 000 - нет искомого значения
в 50 000 000 - 1 искомое значение
в 50 000 000 - 30 000 000 искомых значений
SELECT * FROM EJOU WHERE ejstate = 0
--PLAN (EJOU NATURAL)
ORDER BY ejstate desc, EJOU_ID desc
План
PLAN (EJOU ORDER EJOU_IDX2)
Адаптированный план
PLAN (EJOU ORDER EJOU_IDX2)
------ Performance info ------
Prepare time = 0ms
Execute time = 15ms
Current memory = 1 240 416
Max memory = 50 793 376
Memory buffers = 2 048
Reads from disk to cache = 0
Writes from cache to disk = 6
Fetches from cache = 376
Автор явно упомянул, что будет дополнительная сортировка внутри группы:kdv писал(а):вопрос - а зачем индекс двухсегментный? второй сегмент, конечно, добавляет ему "селективности", но с точки зрения первого сегмента, и что поиск идет по нему, мне кажется это лишнее.
Так что сегментов может быть и больше...Каждая из групп записей по состояниям, имеет еще и собственную сортировку, ...
