Окончательный вердикт. Эта информация немного преувеличена. Этот трюк работает редко и только с mysql, так как в индексе хранится видимость, и можно легко перепрыгнуть. В psql видимость хранится по другому, поэтому подобный трюк с JOIN не сработает так же хорошо, как для mysql, но при этом обычный LIMIT OFFSET будет оптимизирован и сработает намного лучше, чем в mysql.
При этом добавляя условие в JOIN (без чего пагинация редко обходится), и добавляя составной индекс, в обоих случаях результат становится схожим и для mysql и для postgresql
Разница в том, что для psql лучше не использовать join, а для mysql без join тяжеловато выходит
На последнем postgresql для 10кк строк результаты такие:
postgres=# EXPLAIN ANALYZE SELECT * FROM medley ORDER BY n OFFSET 500000 LIMIT 30;
QUERY PLAN
-------------------------------------
Limit (cost=17258.34..17259.37 rows=30 width=37) (actual time=202.280..202.292 rows=30 loops=1)
-> Index Scan using n_idx on medley (cost=0.43..345158.43 rows=10000000 width=37)
(actual time=0.034..176.281 rows=500030 loops=1)
Planning time: 0.123 ms
Execution time: 202.323 ms
(4 rows)
postgres=# EXPLAIN ANALYZE SELECT * FROM medley JOIN
(SELECT n FROM medley ORDER BY n OFFSET 500000 LIMIT 30)
as b ON b.n = medley.n;
QUERY PLAN
------------------------------------------
Nested Loop (cost=12985.27..13239.79 rows=30 width=41) (actual time=132.953..133.150 rows=30 loops=1)
-> Limit (cost=12984.83..12985.61 rows=30 width=4)
(actual time=132.897..132.912 rows=30 loops=1)
-> Index Only Scan using n_idx on medley medley_1 (cost=0.43..259688.43 rows=10000000 width=4)
(actual time=0.032..107.005 rows=500030 loops=1)
Heap Fetches: 0
-> Index Scan using n_idx on medley (cost=0.43..8.45 rows=1 width=37)
(actual time=0.007..0.007 rows=1 loops=30)
Index Cond: (n = medley_1.n)
Planning time: 0.426 ms
Execution time: 133.200 ms
(8 rows)
То есть по сути разница хоть и есть, но всё равно результат далек от того, что хотелось бы
В общем немного упрощенно, но смысл примерно такой:
Допустим у нас есть нужные (простые или составные) индексы по полям для сортировки
Для первого случая подстава в том, что LIMIT работает не до, а после того как была произведена выборка. Допустим, было бы условие «WHERE id > 100000 AND id < 100030», использовался бы индекс, и в лапы LIMIT уже попали бы только 30 записей (и лимит был бы уже не нужен, но такой простой подход для пагинации обычно не удобен)
Но так как никакого условия конкретизирующего нет (а если и есть, то всё равно обычно результат выборки большой), то сначала выбирается вся таблица, и в LIMIT попадает огромное кол-во срок, при этом он не знает где находится 100000 строка, поэтому вынужден пролистывать, пока не отсчитает 100000, чтобы взять лишь 30 строк
Для случая с JOIN в запросе всего лишь «SELECT id», то есть выборка id будет производится не из таблицы, а из оптимизированного индекса, и даже если будет какое-то условие, то мы всё равно в результате получим оптимизированную выборку индекса, в которой более менее точно знаем на какой позиции будет находится 100000 запись, поэтому просто перескакиваем туда и берем 30 записей
Соответственно, сначала мы выбрали нужные id для пагинации используя индекс, а потом просто заджойнили нужные id
Если цель просто сделать оптимизацию пагинации, избавиться от оверхеда limit offset, а не изучить возможности postgesql, то достаточно использовать JOIN
Вместо:
SELECT * FROM test_table ORDER BY id LIMIT 100000, 30
Написать:
SELECT * FROM test_table JOIN (SELECT id FROM test_table ORDER BY id LIMIT 100000, 30) as b ON b.id = test_table.id
«Мы пока не смогли воспроизвести баг, однако, в начале следующей недели выпустим апдейт для iTunes, который добавит дополнительные защитные меры, чтобы такого не происходило.»
«В любом случае, такое поведение iTunes не является штатным и не предусмотрено разработчиками и компанией Apple как нормальное поведение программы, так что сравнение экосистемы Apple с антиутопией Оруэлла «1984» совершенно некорректно.»
Не с существительными пишется раздельно если есть или подразумевается противопоставление.
В первом случае это противопоставление «история не полная, а скомканная»
Не с глаголами всегда пишется раздельно.
Во втором случае это глагол
При этом нет вообще никаких пруфов что у оригинального автора была медиатека и она была удалена (только история без единого скриншота или ссылки на форумы, где он задавал вопросы)
Уже целая статья про это есть, ничего с оригинальным файлом не происходит, цитата из документации Apple Music:
The original files aren't changed.
Если вы сами подключили облако и добавили ваши файлы в itunes, только тогда они попадут в облако и вы сможете их слушать на любом устройстве, самовольной iTunes не проходит по всем дискам, в статье целенаправленно вводят в заблуждение, и тем более ничего сам не удаляет
Уже активно по всему интеренту сыпят предложения переходить на прямых конкурентов типа спотифай или гугль/самсунг музыку
Где-то тут была мысль, мол на geektimes нельзя ничего плохого против Apple сказать, мол сразу адепты заклюют. Но видимо он ошибался, достаточно просто сказать «У меня все файлы удалились, виновата Apple, у них все через одно место» и даже не предоставив ниодного пруфа этого будет достаточно, а все кто пытается логично рассуждать будет заминусован
В оригинальной записи много недосказанностей и дыр. Потому что он утверждает, что его файлы были удалены безвозвратно, хотя четко написано, что Apple Music:
The original files aren't changed.
Более того, я точно так же добавил файлы в itunes после того как подключил Apple Music, и все файлы до сих пор лежат на своих местах на диске
Это сколько же раз надо нажать, что-бы удалить 200гб?
Достаточно делать это систематически, и не обязательно по одному файлу за раз (wav весят не мало)
Тоже немного не в тему, но с чего вообще можно подумать, что для дальнейшей работы надо оплатить что-то, если очень легко проверить, что у вас никто не отобрал возможность пользоваться, просто попробовав и дальше попользоваться?
Закончилось место, вам предложили его расширить, всё логично, отказались — можно пользоваться дальше бесплатными 5Гб
Сам iCloud у вас уже есть и он бесплатно включен, за него платить не надо
Ничего не произойдет, так как iTunes синхронизирует только ту музыку, что была добавлена в iTunes, самовольно он не сканирует диск
В оригинальной статье (и вообще в целом) не говорится о том, что iTunes «После подписки на Apple Music программа iTunes сканирует жёсткий диск и проводит каталогизацию всех найденных музыкальных файлов (MP3, WAV)», это уже додумка
При этом добавляя условие в JOIN (без чего пагинация редко обходится), и добавляя составной индекс, в обоих случаях результат становится схожим и для mysql и для postgresql
Разница в том, что для psql лучше не использовать join, а для mysql без join тяжеловато выходит
То есть по сути разница хоть и есть, но всё равно результат далек от того, что хотелось бы
Допустим у нас есть нужные (простые или составные) индексы по полям для сортировки
Для первого случая подстава в том, что LIMIT работает не до, а после того как была произведена выборка. Допустим, было бы условие «WHERE id > 100000 AND id < 100030», использовался бы индекс, и в лапы LIMIT уже попали бы только 30 записей (и лимит был бы уже не нужен, но такой простой подход для пагинации обычно не удобен)
Но так как никакого условия конкретизирующего нет (а если и есть, то всё равно обычно результат выборки большой), то сначала выбирается вся таблица, и в LIMIT попадает огромное кол-во срок, при этом он не знает где находится 100000 строка, поэтому вынужден пролистывать, пока не отсчитает 100000, чтобы взять лишь 30 строк
Для случая с JOIN в запросе всего лишь «SELECT id», то есть выборка id будет производится не из таблицы, а из оптимизированного индекса, и даже если будет какое-то условие, то мы всё равно в результате получим оптимизированную выборку индекса, в которой более менее точно знаем на какой позиции будет находится 100000 запись, поэтому просто перескакиваем туда и берем 30 записей
Соответственно, сначала мы выбрали нужные id для пагинации используя индекс, а потом просто заджойнили нужные id
Вместо:
Написать:
«В любом случае, такое поведение iTunes не является штатным и не предусмотрено разработчиками и компанией Apple как нормальное поведение программы, так что сравнение экосистемы Apple с антиутопией Оруэлла «1984» совершенно некорректно.»
«Неполная история вызывает вопросы» — тогда да, слитно
Но тут это противопоставление, поэтому раздельно
В первом случае это противопоставление «история не полная, а скомканная»
Не с глаголами всегда пишется раздельно.
Во втором случае это глагол
Уже целая статья про это есть, ничего с оригинальным файлом не происходит, цитата из документации Apple Music:
Если вы сами подключили облако и добавили ваши файлы в itunes, только тогда они попадут в облако и вы сможете их слушать на любом устройстве, самовольной iTunes не проходит по всем дискам, в статье целенаправленно вводят в заблуждение, и тем более ничего сам не удаляет
Уже активно по всему интеренту сыпят предложения переходить на прямых конкурентов типа спотифай или гугль/самсунг музыку
Где-то тут была мысль, мол на geektimes нельзя ничего плохого против Apple сказать, мол сразу адепты заклюют. Но видимо он ошибался, достаточно просто сказать «У меня все файлы удалились, виновата Apple, у них все через одно место» и даже не предоставив ниодного пруфа этого будет достаточно, а все кто пытается логично рассуждать будет заминусован
Более того, я точно так же добавил файлы в itunes после того как подключил Apple Music, и все файлы до сих пор лежат на своих местах на диске
Достаточно делать это систематически, и не обязательно по одному файлу за раз (wav весят не мало)
Закончилось место, вам предложили его расширить, всё логично, отказались — можно пользоваться дальше бесплатными 5Гб
Сам iCloud у вас уже есть и он бесплатно включен, за него платить не надо
Нет, Apple Music не удаляет файлы с вашего диска — пока вы сами не удалите их
В оригинальной статье (и вообще в целом) не говорится о том, что iTunes «После подписки на Apple Music программа iTunes сканирует жёсткий диск и проводит каталогизацию всех найденных музыкальных файлов (MP3, WAV)», это уже додумка