Скорость limit на таблицах с фиксированной длиной полей

[Фанат]

Скорость limit на таблицах с фиксированной длиной полей

Я, конечно, понимаю, что "протестируй и нам скажи".
но всё же.
известно (из разных тем про случайные выборки), что лимит на больших значениях тормозит.
однако, теоретически, (вспомним хотя бы известную статью Джоэля Спольского), при фиксированной длине записи, вычислить любой оффсет - это одна операция умножения.

Так вот интересно - прав ли я в своём предположении, что на таблицах с фиксированной длиной полей лимит не тормозит при любых значениях?

А может быть, я просто гоню даже на лимит в таблицах с переменной длиной записей?

 

[Steamroller]

Так длина записей ни при чем.
Если структура таблиц и запрос (точнее, эквивалентный запрос без limit) позволяют выбирать записи без сортировки и фильтрации по данным, тогда limit не тормозит.
Если только без сортировки - то тормозит, но не сильно и пропорционально начальному значению.
Если с сортировкой - тормозит всегда.

Уже скоро вроде должны сделать что-то вроде оракловых materialized views и курсоры, тогда проблема по большей части в прошлом останется.

 

[Апельсин]

оракловых materialized views

это где вы такое взяли? Их нет и на 5.0 (т.е. на самое ближайшее время) не планируется.

 

[Фанат]

Да, пожалуй, при наличии фильтров и сортировок длина не при чём.
Но вот при простой выборке - интересно.

 

[Steamroller]

это где вы такое взяли? Их нет и на 5.0 (т.е. на самое ближайшее время) не планируется.

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

Да, пожалуй, при наличии фильтров и сортировок длина не при чём.
Но вот при простой выборке - интересно.

Хм. Я тут поковырялся еще, в общем даже при самом простом запросе с limit n,m база сканирует индекс с начала и пока не получит нужное число записей.
То есть вычислять оффсет не пытается.

 

[Фанат]

Спасибо.
Мда, честно говоря, я так и думал.
А жаль =)