iBase.ru Forum

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

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

WildSery писал(а):У меня хотя бы отсортировано по дате выбирается во внешнем, и новое значение получается только при смене даты...

Ничего не понял. У тебя в запросах есть некая сортировка по дате. Наверное по архиву. Структура таблицы похожа? Ты выбираешь сразу поток данных из архива, а не 700k раз по разу?

И тут приходится отступить на шаг и подумать о том, насколько незыблемы исходные представления о решаемой задаче и насколько нужно то, что кажется интуитивно нужным. Один намёк такого рода сегодня ты уже пропустил мимо ушей. Как раз и хотел может быть и отступить :) Просто помню, какое впечатление ...

Единственно - на некоторых данных одной и той же структуры этот композит хорош, на некоторых более полезными могут оказаться два раздельных индекса по инту и дате. Похоже, что такое и происходит с различием эффективности INDEX и ORDER у разных клиентов. Попробуем раздельные индексы. Если же нужно "...

Итак результаты измерений. В них участвуют следующие запросы: 0) Текущая реализация (план INDEX). SELECT FIRST 1 Balance FROM AccArch WHERE AccID = :i_AccID AND OperDate <= :i_Date PLAN (ACCARCH INDEX (ACCARCH_PK)) ORDER BY AccID DESC, OperDate DESC 1) Пожелание Attid убрать AccID из сортировки SELE...

Мм, там ведь кроме даты есть AccID у меня и parent с ttype у тебя. То есть нечто, для чего хранятся данные о чем-то. И вроде как поиск по ним должен осуществляться. Одно из сомнений как раз и было в порядке следования сегментов индекса.

Посмотрел то обсуждение на sql.ru. Влад там предложил вариант, в котором сегмент даты идет первым в индексе. Добавил к тестовой процедуре этот вариант и тот, что ты привел. Посмотрим, что получится.

Да, сейчас у всех клиентов кроме одного используется 1.5. Насколько я знаю, возможность явно совмещать INDEX и ORDER появилась в 2.0. Согласен, много раз говорилось, что 1.5 может так делать и не говорить об этом в плане. Если план не задавать явно, получаю PLAN (ACCARCH ORDER ACCARCH_PK) Попрошу Ан...

Да, один. Видимо осталось от варианта, когда там был план ORDER. Да, некоторое время там был план ORDER и производительность тоже устраивала сотрудников Антона, но в другом случае оказалась неприемлемой, перешли к варианту с планом INDEX. Под архивацией в данном случае понимается операция откладыван...

Прикольно. Я вообще не люблю писать функции с FREE_IT, возвращаю через входной параметр всегда, пусть у сервера голова болит, как выделить и куда дальше девать память, потому есть своя DateToStr :) В нашей реализации этих функций именно так и сделано. Но они появились позже, чем понадобились сотруд...

Осталось ещё понять, на кой она вообще на сервере нужна... Для выдачи в результат запроса даты в форматированном виде для упрощения последующей обработки видимо. Встроенного механизма для этого я не знаю, простое преобразование в строку потом тяжело разобрать. Диалект первый. Да там не запрос, а сх...

Задачу, которая в той процедуре является узким местом, описал в http://forum.ibase.ru/phpBB2/viewtopic.php?p=27445

Буду благодарен за любую помощь. И все наши клиенты наверное тоже.

Всем привет! Есть таблица архива счетов, назовем её AccArch. Вот такая (несущественное опущено): CREATE TABLE AccArch ( OperDate DATE NOT NULL, AccID INTEGER NOT NULL, Balance DOUBLE PRECISION NOT NULL ); В случае, если в некоторую дату по счету были проводки, в эту таблицу сохраняется баланс счета ...

а) на превышении предусмотренной глубины рекурсии Явной рекурсии нет, причин для срабатывания триггеров тоже. б) на каких-то старых (а 1.5.2 - далеко не девочка) версиях при использовании Break в For Select (причём не всегда) Break нет. Но клиент и сервер разные, есть шанс на то, что это оно. Говор...

запрос который ты показал не может работать час, даже при десятках милионов, или там что-то важное забыли или одно из двух =) Я рассказал, что там ещё. Самые тяжелые - вызовы процедур, читающих из архивной таблицы по счетам. Я не знаю, как ускорить без архивации состояния всех счетов за каждый день...

hvlad писал(а):Протокол менять не пробовал ?

Говорят, что в строке connect'а стоит IP. То есть протокол TCP/IP. Стоит пробовать локальный протокол? Воспроизводимый пример может быть с помощью while удастся получить, подумаем.

если вместо цыферок запрос который работает хотя бы сотую долю секунду, он будет выполнятся "единицы миллионов" раз или 2 часа на миллион. Не уверен, что понял, о чем ты. Два момента: - по IN не используются индексы - с производительностью проблемы нет, есть проблема с ошибкой при выборке большого ...

использовать не советуют , чтобы не столкнутся когда нибуть с невостановимым бекапам а про невосстановимый backup если честно не слышал. Тут наверное имеется в виду использование RDB$ имен индексов в планах. И может быть в меньшей степени о изменениях индексов, после чего они перестают быть пригодн...

Всем привет. Вот основной запрос в процедуре. SELECT Agreements.BranchID, /* список полей */ PrivateClients.ClientPrivID FROM Accounts, Agreements, PrivateClients WHERE Accounts.ContractID = Agreements.ContractID AND PrivateClients.ClientPrivID = Agreements.ClientPrivID AND agreements.enrolled <= :o...