Как организовать разбивку результатов запроса по страницам?

[romutis]

Crazy,

В результате у тебя будет:
1) full scan по таблице phones_head
2) index scan по таблице phones_body
3) Merge join таблиц (!)


Результат изрядно проигрывает одному-единственному index scan'у по таблице phones_body, предложенному в моем варианте.

 

[Crazy]

Автор оригинала: romutis
В результате у тебя будет:

Это данные oracle или твое предсказание? Если первое, то очень странно, что Oracle начать писать план в таком формате.

 

[romutis]

Это было не предсказание, но утверждение. Или тебе нужно показать cost операции с точностью до единицы?

 

[Crazy]

Т.е. ты НЕ проводил эксперимент?

Я, собственно почему интересуюсь: MySQL для приведенного примера построил куда более оптимальный план -- без tablescan.

Поэтому выходит, что либо оптимизатор в Oracle НАСТОЛЬКО хуже, чем в MySQL, либо твое мнение о реальности несколько невернО...

 

[Crazy]

Кстати, напоминаю, что *_head нам нужен реально только при выборке ВСЕХ записей. Если мы все равно наложили какое-то условие, то необходимости в ее использовании уже нет.

На скорости это, правда, не отражается.

P.S. Продолжают ждать публикации ораклового плана запроса...

 

[aloner]

Кому тут план? ;-)

Киньте в ПМ код для таблиц и сам запрос - запостю план.

 

[Ямерт]

"Всё идёт по плану
Все ушли за планом..."


Мне очень стыдно, но я пока относительно решил проблему "топорным" методом:
1) выполняю запрос, фетчу данные в массив;
2) возвращаю нужный array_slice() от этого массива.

Сложность O(n^2), но единственная экономия - на выводе данных.
Сейчас посмотрю насчёт этого BULK COLLECT...
Кстати, как вызвать PL/SQL код? Как обычный SQL-запрос? Или надо создать процедуру?

 

[Crazy]

Автор оригинала: aloner
Кому тут план? ;-)

Я уже сам посмотрел -- сразу по приходу на работу. Нет там, разумеется, никакого tablescan. Более того, мой первый вариант также его не вызывает, так что извращаться вообще незачем.

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

 

[Crazy]

Автор оригинала: Ямерт
Мне очень стыдно, но я пока относительно решил проблему "топорным" методом:
1) выполняю запрос, фетчу данные в массив;
2) возвращаю нужный array_slice() от этого массива.

Если количество записей не сотни тысяч, то этот способ часто работает достаточно хорошо.

 

[chira]

О чем вы здесь спорите?
trent привел реальный рабочий пример.
к теме об извращении, совет который дал romutis с fetch-ем - это гораздо большее извращение.

в любом случае основной запрос нужно будет выполнить.
так что об эффективности его нет смысла говорить.

остается сравнить , что будет эффективнее select&subselect Oracl-а или PHP c fetch-ем?

если нам к примеру нужно плучить записи с 99120-99129,
то сами подумайте вытаскивать 99120 записей в PHP - это не извращение?

 

[.des.]

chira вот мы вчера об этом с Ямертом говорили (насчет fetcha и пришли к такому же выводу).

Вот меня интересует - если таблица миллион записей. Ну допустим. Надо организовать шагание по ней с шагом 100.
Вариант trenta?
(бедный Oracle)

 

[Ямерт]

У нас сервер БД - больная тема. Тормозит он нещадно. К сожалению, нет специалиста, который бы оптимизировал работу сервера. Поэтому вариант trent'a мне не подходит, хотя, имхо, он более изящный.

 

[romutis]

chira,
Я бы не был таким уверенным...

В варианте от trent'a - вытаскиваются ВСЕ записи из таблицы в сабселекте и потом из них выбирается N нужных.

В моем варианте - выборка всех записей из таблицы не производится (да будет вам известно, что курсор не выбирает все записи зараз). Да и выборка идет (при правильном дизайне БД) по индексу, а не с помощью full-scan как это делается при селекте всех записей.

если нам к примеру нужно плучить записи с 99120-99129, то сами подумайте вытаскивать 99120 записей в PHP - это не извращение?

А если эти записи находятся в таблице с общим кол-вом записей в 1 миллион, то выбирать весь миллион для того, чтобы выбрать потом 10 записей из полученного резалтсета - это не извращение? Я понимаю, что селект из селекта выглядит изящнее с точки зрения программиста (никаких лишних движений при минимуме написанного кода) - но с моей точки зрения (Oracle DBA) - это неправильный подход к созданию оптимального кода.

P.S. Давайте определимся господа, о каком кол-ве данных идет речь? Если о 100 записях в таблице - то чего мы пупы рвем? "Ставить MySQL и млеть от Щастья!" Если же мы говорим о большОм кол-ве данных - то давайте оптимизировать запросы, исходя из оракловских реалий.

P.P.S. Crazy, про EXPLAIN PLAN я помню. Ну нет у меня под рукой телефонного справочника - не пишу я их, придется в свободное время родить структуру и, главное - данные для теста.

 

[Ganer]

вставлю свое ИМХО
у меня таблицы которые нада выдавать постранично ~100 тыс. записей - разницы особой в методах не увидел, в свое время ... так что было бы интересно посмотреть на чужие результы
p.s. а я fetchу

 

[Ganer]

сейчас у себя поэксперементировал, на табличке в 27тыс методом fetch в 8 раз медленее ...

 

[chira]

Для организации постраничного вывода тебе придется использовать ORDER BY, как Oracle отсортирует правильно записи если не получит все?

 

[Crazy]

Для сортировки достаточно использовать индексы.

 

[chira]

romutis:
если ты DBA и получается рассматриваешь только сторону оракля.
посмотри на ораклю вместе с PHP.

Вот и Ganer вставил свое слово.

 

[romutis]

Chira,

А как можно оценивать производительность работы с базой только со стороны девелопера? По кол-ву минимально затраченных усилий?

А PHP - не держим-с.

 

[fisher]

кто-нибудь уже выведет сюда explain plane или нет ? насчет выборки с сортировкой (мол, достаточно хинт - индекс указать) - а если у нас джойн и сортировка по полям из нескольких таблиц? а если у меня вообще юнион вьюёв (ну вообще-то те же джойны, конечно но ещё с union )?
мне почему-то кажется, что fetch (элегантно - не вопрос) будет работать только для выборки сущностей из одной таблицы? почему прошу план - оптимайзер у оракла крутой, и не всё так очевидно. самому мне конечно больше сабселекты нравятся