x
Size: a a a
2021 December 09
MO
Недавно узнал, что в Постгресе при использовании конструкции
А как в Оракле с этим? 🤔
select *Даже при наличии индекса на (x,y) база считает 1010 строк, а не 10.
from table
where x = ?
order by y
offset 1000
limit 10
А как в Оракле с этим? 🤔
DG
я думал во всех базах так. не отсчитав 1000, нельзя понять что отдать нужно с 1000й по 1010ю
MO
Поменял запрос, чтобы было два поля.
MO
Мне казалось, что у базы есть эффективный способ скипнуть первые N записей в индексе, т.к. там данные хранятся в отсортированном порядке
MO
Запрос читает данные в том же порядке, что и в индексе
IG
Explain можете показать?
KL
где-то была хорошая статья про то, как правильно делать пагинацию. не могу найти...
IG
я на хабре видел такую статью. но к сожалению все девелоперы делают пагинацию через одно место. всякие rownum
MO
Да там ничего интересного, offset 0 limit 1010 и offset 1000 limit 10 показывает одинаковое количество считанных buffers
DG
они по моему при таблице по умолчанию (heap organized) хранятся не по порядку. сканировать индекс или читать записи не принципиально думаю, в любом случае нужно "просмотреть" 1000 чтобы понять что следующую 1001ю нужно извлечь
IG
но хотелось бы доказательства
DS
Всем привет.
Возможны ли какие то ситуации или баг при котором возможен двойной вызов процедуры т.е. ее вызвали один раз, но фактически она выполнилась два раза.
RAC - 12.1
Возможны ли какие то ситуации или баг при котором возможен двойной вызов процедуры т.е. ее вызвали один раз, но фактически она выполнилась два раза.
RAC - 12.1
R
Если найдете сообщите пожалуйста. У нас вендор так сделал
Правда еще вендор делает через TASKID. Типа сначала строит динамический sql, инсертит столбец идентификатора результата запроса и TASKID в LISTIDs. что чуточку быстрее чем leftjoin
where rw between ((:pPageNo-1)*:pRowN+1) and ((:pPageNo)*:pRowN)Правда еще вендор делает через TASKID. Типа сначала строит динамический sql, инсертит столбец идентификатора результата запроса и TASKID в LISTIDs. что чуточку быстрее чем leftjoin