hi all

В некоторой базейке есть вот такая небольшая табличка:


full-scan по этой табличке потребует 413'341'388 фетчей, что в точности равно (число строк + data_page_slots) * 2 + Pointer_pages =
(200000000+6666568)*2 + 8252.
Не понимаю, зачем ему надо лазить по два раза для каждой записи как на обычную DP, так и data_page_slots.
И еще: если на одной DP размещается N>=2 записей, то почему нельзя считать их за 1 фетч ?

Таблоидfull-scan по этой табличке потребует 413'341'388 фетчей, что в точности равно (число строк + data_page_slots) * 2 + Pointer_pages =
(200000000+6666568)*2 + 8252.
Не понимаю, зачем ему надо лазить по два раза для каждой записи как на обычную DP, так и data_page_slots.
И еще: если на одной DP размещается N>=2 записей, то почему нельзя считать их за 1 фетч ?Вспомнил.
hvlad, 24.04.2010, http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=753376&msg=8683003 0 записей
Читаем PP. На ней нет DP. Итого 1 фетч.

1 запись.
Читаем PP. Читаем DP. Возвращаем запись №1. 2 фетча.
Читаем PP. Читаем DP. Нет записи №2. 2 фетча.
Читаем PP. Нет другой DP. Возвращаемся. 1 фетч.
Итого 5 фетчей.

2 записи.
Читаем PP. Читаем DP. Возвращаем запись №1. 2 фетча.
Читаем PP. Читаем DP. Возвращаем запись №2. 2 фетча.
Читаем PP. Читаем DP. Нет записи №3. 2 фетча.
Читаем PP. Нет другой DP. Возвращаемся. 1 фетч.
Итого 7 фетчей.

Вопрос к Источникам Света.
Запросы, в которых к таблицам применяется full scan и нет доп. условия отбора по индексу, не так уж редки: всякие там like / containing или similar to на справочных таблицах типа контрагентов, изделий и проч.
То есть, движок должен по-любому прочесть эту таблицу полностью. Да, эти справочники не по 200 млн записей, но и не по 10 тыс. И главное - "в них постоянно кто-то лезет" (сужу по своему продуктиву).

Если бы движок однократно прошелся по всем PP и составил по ним уникальный список всех DP этой таблицы, то затраты уменьшились бы вдвое.

Есть ли этот или подобный "ход конём" в громадье планов ФБ-3.х ?

dimitrво-первых, я тебе уже предлагал забыть про "громадье планов", ибо через два-три месяца feature freeze.0xFF, конечно, но: есть ли шанс увидеть закоммиченным в 3.0 release патч Влада на онлайн-валидацию ?
dimitrВо-вторых, число PP много меньше числа DP, откуда тут "затраты уменьшились бы вдвое"?1) прочитали сразу все PP таблицы, составив список DP этой таблицы.
2) прочитали только один раз каждую DP (по составленному списку).
Разумеется, это годится только для full scan'ов, когда ясно, что молотить придётся всю таблицу.
dimitrВ третьих, если "в них постоянно кто-то лезет", то PP будут в кеше и прочитать их будет дешево.А разве они не будут постоянно вытесняться из кеша ввиду того, что был фулл-скан ?
dimitrВ четвертых, ты как всегда игнорируешь конкуренцию и правила надежного обхода страниц.Ну так чем меньше читаем, тем лучше будет "погода" при конкуренции, нет разве ? И что такое "правила надежного обхода" при селекте ?

dimitrТаблоидА разве они не будут постоянно вытесняться из кеша ввиду того, что был фулл-скан ?
ты же вроде тестировал, что фуллскан никого не вытесняетне, я про обратную ситуацию: dp, прочтённые фулл-сканом, будут первыми на вылет из кеша - именно по той причине, что они читались ТАК, фулл-сканом. В писании же говорится русским по белому об этом: http://www.ibase.ru/devinfo/dataaccesspaths.htm#chapter111 1.1.1. Полное сканирование
Как только на странице нет больше данных и надо фетчить следующую, то текущая страница освобождается с признаком LRU (least recently used), уходя в "хвост" очереди и будучи таким образом первым кандидатом на удаление из кеша.
dimitrТаблоидИ что такое "правила надежного обхода" при селекте ?по указателю от PP к DP. Иначе твой список стухнет при первом же конкурентном изменении и прочитаешь ты хрен пойми что.А что сейчас ? Вот развёртка во времени запроса select count(*) from t при общем числе записей = 2:
Что будет, когда PP прочитали в момент t20, полезли в следующий момент (t25) за DP, а она уже "протухла" ввиду конкуренции ?

dimitrэто гарантируется порядком блокировок при переходе по указателю. DP не может "протухнуть" пока мы держим PP.вооот! это оч-чень хорошо :-)
Значит, при фулл-скане можно:
1) залочить, затем прочитать PP-1 и составить список всех DP, которые там сидят;
2) обрабатывать список: перейти на каждую DP из него и выдёргивать оттуда данные;
3) высвободить PP-1;
4) залочить, затем прочитать PP-2 и составить список всех DP, которые там сидят
и т.п. для всех прочих PP этой таблицы.

Итого получается, что сканируем только 1 раз все PP и все DP этой таблицы.
Недостаток вижу только один: время удержания блокировки РР больше, чем сейчас.
Но зато сейчас на одну и ту же РР лезем по многу раз с этой же блокировкой.

Ы ?

Dimitry SibiryakovА остальные должны нервно курить в сторонке пока ты маешься этой фигнёй, да...А это еще вопрос, сколько они будут покуривать, пока я 10 раз буду лочить одну и ту же РР, пусть и в разное время. "Эксперимент - критерий истины" ((С) Галилей ?).

Dimitry SibiryakovОсновное правило избегания дедлоков: держать блокировку только на одной странице
одновременно. Его можно было бы местами нарушать, но не в этом случае.Мну кажется, что ты ошибся. Основное правило избежать именно deadlock'ов - это запрашивать блокировки всеми аттачами в строго определённом порядке, обязательном для каждого аттача. Какие предпосылки для дедлока будут в случае, когда всегда сначала лочится РР, а затем DP ?