Вопрос оптимизации чтения данных из архива

Dmitry Dyachenko

Насчет разницы между "<" и "<=" то было таки необычное поведение, при котором у нас >1 выбирало дольше, чем >=2 т.к. большинство записей содержало 1 в этом поле и сервер просматривал их все. Вроде давно исправлено. Да и тут совсем не тот случай.

WildSery · Сообщение **WildSery** » 28 фев 2008, 16:03

Dmitry Dyachenko писал(а):Структура таблицы похожа?

Нет.

Dmitry Dyachenko писал(а):Ничего не понял.

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

Dmitry Dyachenko

А если не у меня. Задачи ведь похожие по сути. Тебе тоже нужно узнавать нечто на дату. И это нечто как-то хранится. Причем так, что получается делать выборки на дату одним запросом. Вот это и интересно.

Attid · Сообщение **Attid** » 28 фев 2008, 19:13

Dmitry Dyachenko писал(а):Причем так, что получается делать выборки на дату одним запросом. Вот это и интересно.

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

WildSery писал(а):
Attid писал(а):никак не пойму как этот запрос может влиять, когда сам он доли секунд выполняется =/
В смысле? Он же 700 тыс. раз выполняется. Сравни время выполнения с пустой прогонкой - больше половины времени занимает.

это то я как раз понял, я про то что пока это выполняется милион раз выиграть время там сложно, только изменением структуры БД, которое примерно обрисовал в преведущем сообщении.

WildSery · Сообщение **WildSery** » 29 фев 2008, 12:14

[quote="Dmitry Dyachenko"][/quote]
У меня тут мысля появилась, пока что бредовая, её нужно подумать.
Покажи или расскажи как у тебя дата среза формируется.

Merlin · Сообщение **Merlin** » 29 фев 2008, 13:01

WildSery писал(а):
Dmitry Dyachenko писал(а):
У меня тут мысля появилась, пока что бредовая, её нужно подумать.
Покажи или расскажи как у тебя дата среза формируется.

Tmp-table и двухпроходность? Если проблема таки в скане, то от неё всё равно не уйдёшь, а вот запросы, использующие результат (если таковые есть) могут кардинально ускориться. В смысле после переписывания и их и всего кода процедуры

Я, в процессе оппонирования любителям tmp оговаривался как-то, что у меня их парочка таки есть. Именно этот случай - сбор агрегатов с первички и пересечения трёх таких слабозависимых архивов периодической атрибутики. Писать в лоб - просто крышу срывает, а получишь сначала упорядоченный срез архивов и всё проздрачно.

fmilovidov · Сообщение **fmilovidov** » 13 мар 2008, 22:36

Dmitry Dyachenko писал(а):А если не у меня. Задачи ведь похожие по сути. Тебе тоже нужно узнавать нечто на дату. И это нечто как-то хранится. Причем так, что получается делать выборки на дату одним запросом. Вот это и интересно.

Я эту проблему решаю путем хранения не даты изменения, а интервала валидности. В этом случае нечто на дату выбирается одним between. На моих данных (14 млн записей) все работает достаточно быстро. Хотя конечно больше гимора с insert, update и delete.

WildSery · Сообщение **WildSery** » 14 мар 2008, 19:29

Такая схема хранения у меня тоже есть. И выбор по схеме

Код: Выделить всё

select * from table where type = :type and :adate between date_beg and date_end

может быть быстрее, особенно при наличии индекса (TYPE, DATE_BEG, DATE_END)
Но тут всё равно ещё и от распределения данных зависимость есть.

Merlin · Сообщение **Merlin** » 14 мар 2008, 19:58

Хранение диапазонов и обеспечение их непересекаемости есть великое граблеполе в конкурентной многопользовательской среде. Если есть возможность организационно-естественно добиться однопользовательства в информационных функциях управления диапазонами и подкрепить резервированием таблиц на момент их выполнения - в общем нормально, хоть и всё равно немного хлопотно.