Быстрое кроссплатформенное HTML5 приложение на Framework7

Напишите автору об ошибках либо сюда, либо сюда:
https://github.com/nolimits4web/framework7/issues
http://forum.framework7.io/#!/bugs-and-issues

Подобные баги обычно легко исправляются

Чем полезен мономорфизм?

Допустим теоретический пример:

function f(o) {
    let r = '';
    for(let key in o) {
        r += `${key} = ${o[key]}\n`;
    }
    return r;
}

// определяем рабочую переменную
let temp = {};
let result = [];

//первый набор данных
temp = {x:0, y:1};
//шаблонная работа с набором данных
result.push(f(temp));

//второй набор данных
temp = {a:1, b:2}
//шаблонная работа с набором данных
result.push(f(temp));
//и так далее, много разных наборов

Данные разные, но работа с ними примерно одинакова. Например, в jade, при определенном сценарии использования, по сути что-то такое и есть, когда на входе данные с атрибутами, а на выходе сформированная html строка

Получается, пока атрибуты примерно одинаковые (всегда только class или href), то всё работает быстро, как только начали в шаблонизатор попадать разнообразные атрибуты (хотя бы 1 раз на тысячу вызовов), f() переходит рано или поздно в «мегаморфизм» и оптимизации будут минимальны

И допустим, чтобы оставаться быстрым для стандартных случаев, уже нужно самим вводить вручную фильтрацию на атрибуты — если какой-то стандартный набор, то вызываем f1(), если что-то новенькое то f2(), если сходу видно что что-то экзотическое (допустим attributes.lenght > 5), то вообще f3(). При этом, естественно, f1(), f2(), f3() будут одинаковыми

Что-то в этом духе или это бессмысленно?

PostgreSQL — не Rocket Science. Почем сейчас яйца?

Используйте https://www.adminer.org/ (один файл, легковестный, во многом удобнее)
Что с myqsl, что с postgresql (и другими базами) работа в итоге будет одинаковой

Пять способов пагинации в Postgres, от базовых до диковинных

Для Int на той же таблице по сути разницы нет:
Просто OFFSET: Execution time: 202.323 ms
Вариант с WITH: Execution time: 138.158 ms
Вариант с JOIN: Execution time: 133.200 ms

explain

postgres=# EXPLAIN ANALYZE WITH temp_rows AS (
        SELECT n 
        FROM medley 
        ORDER BY n OFFSET 500000 
        LIMIT 30
)
SELECT * FROM medley WHERE medley.n = ANY(ARRAY(SELECT n FROM temp_rows)::Int[]);
                                                                         QUERY PLAN                                                                          
-------------------------------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using n_idx on medley  (cost=12986.44..13034.53 rows=10 width=38) (actual time=138.009..138.107 rows=30 loops=1)
   Index Cond: (n = ANY ($1))
   CTE temp_rows
     ->  Limit  (cost=12984.63..12985.41 rows=30 width=4) (actual time=137.945..137.953 rows=30 loops=1)
           ->  Index Only Scan using n_idx on medley medley_1  (cost=0.43..259694.04 rows=10000374 width=4) (actual time=0.038..110.982 rows=500030 loops=1)
                 Heap Fetches: 0
   InitPlan 2 (returns $1)
     ->  CTE Scan on temp_rows  (cost=0.00..0.60 rows=30 width=4) (actual time=137.950..137.968 rows=30 loops=1)
 Planning time: 0.219 ms
 Execution time: 138.158 ms
(10 rows)

Решил так же проверить, как этот вариант будет вести для более частых малых OFFFSET (5000, например), тут уже вариант с WITH стал сильно отставать

Результаты для OFFSET 5000 LIMIT 30:
Просто OFFSET: Execution time: 3.380 ms
Вариант с WITH: Execution time: 8.379 ms
Вариант с JOIN: Execution time: 1.788 ms

Apple прислала своих людей к пользователю, у которого пропали файлы в iTunes

Потому что apple не признала наличие бага, а допустила наличие такой возможности (и теперь пытается хотя бы один раз воспроизвести его)

Пять способов пагинации в Postgres, от базовых до диковинных

В первом запросе забыли ORDER BY n, поэтому seq scan (результат хоть и быстрее, но выборка будет не та, которая нужна)

https://habrahabr.ru/post/301044/#comment_9615682

Пять способов пагинации в Postgres, от базовых до диковинных

Окончательный вердикт. Эта информация немного преувеличена. Этот трюк работает редко и только с mysql, так как в индексе хранится видимость, и можно легко перепрыгнуть. В psql видимость хранится по другому, поэтому подобный трюк с JOIN не сработает так же хорошо, как для mysql, но при этом обычный LIMIT OFFSET будет оптимизирован и сработает намного лучше, чем в mysql.

При этом добавляя условие в JOIN (без чего пагинация редко обходится), и добавляя составной индекс, в обоих случаях результат становится схожим и для mysql и для postgresql

Разница в том, что для psql лучше не использовать join, а для mysql без join тяжеловато выходит

Пять способов пагинации в Postgres, от базовых до диковинных

Всмысле хоть с join намного легче запрос, но это просто потому что без join намного тяжелее чем тут

Пять способов пагинации в Postgres, от базовых до диковинных

Проверил на mysql для таблицы 6кк строк, разница примерно такая же

Пять способов пагинации в Postgres, от базовых до диковинных

На последнем 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)

То есть по сути разница хоть и есть, но всё равно результат далек от того, что хотелось бы

Пять способов пагинации в Postgres, от базовых до диковинных

В общем немного упрощенно, но смысл примерно такой:
Допустим у нас есть нужные (простые или составные) индексы по полям для сортировки

Для первого случая подстава в том, что LIMIT работает не до, а после того как была произведена выборка. Допустим, было бы условие «WHERE id > 100000 AND id < 100030», использовался бы индекс, и в лапы LIMIT уже попали бы только 30 записей (и лимит был бы уже не нужен, но такой простой подход для пагинации обычно не удобен)

Но так как никакого условия конкретизирующего нет (а если и есть, то всё равно обычно результат выборки большой), то сначала выбирается вся таблица, и в LIMIT попадает огромное кол-во срок, при этом он не знает где находится 100000 строка, поэтому вынужден пролистывать, пока не отсчитает 100000, чтобы взять лишь 30 строк

Для случая с JOIN в запросе всего лишь «SELECT id», то есть выборка id будет производится не из таблицы, а из оптимизированного индекса, и даже если будет какое-то условие, то мы всё равно в результате получим оптимизированную выборку индекса, в которой более менее точно знаем на какой позиции будет находится 100000 запись, поэтому просто перескакиваем туда и берем 30 записей

Соответственно, сначала мы выбрали нужные id для пагинации используя индекс, а потом просто заджойнили нужные id

Пять способов пагинации в Postgres, от базовых до диковинных

Если цель просто сделать оптимизацию пагинации, избавиться от оверхеда 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

Нет, Apple Music не удаляет файлы с вашего диска — пока вы сами не удалите их

«Мы пока не смогли воспроизвести баг, однако, в начале следующей недели выпустим апдейт для iTunes, который добавит дополнительные защитные меры, чтобы такого не происходило.»

«В любом случае, такое поведение iTunes не является штатным и не предусмотрено разработчиками и компанией Apple как нормальное поведение программы, так что сравнение экосистемы Apple с антиутопией Оруэлла «1984» совершенно некорректно.»

Нет, Apple Music не удаляет файлы с вашего диска — пока вы сами не удалите их

Если бы было:
«Неполная история вызывает вопросы» — тогда да, слитно
Но тут это противопоставление, поэтому раздельно

Нет, Apple Music не удаляет файлы с вашего диска — пока вы сами не удалите их

Там то же правило с противопоставлением

Нет, Apple Music не удаляет файлы с вашего диска — пока вы сами не удалите их

Не с существительными пишется раздельно если есть или подразумевается противопоставление.
В первом случае это противопоставление «история не полная, а скомканная»

Не с глаголами всегда пишется раздельно.
Во втором случае это глагол

Почему Apple удаляет файлы с компьютеров пользователей

При этом нет вообще никаких пруфов что у оригинального автора была медиатека и она была удалена (только история без единого скриншота или ссылки на форумы, где он задавал вопросы)

Уже целая статья про это есть, ничего с оригинальным файлом не происходит, цитата из документации Apple Music:

The original files aren't changed.

Если вы сами подключили облако и добавили ваши файлы в itunes, только тогда они попадут в облако и вы сможете их слушать на любом устройстве, самовольной iTunes не проходит по всем дискам, в статье целенаправленно вводят в заблуждение, и тем более ничего сам не удаляет

Уже активно по всему интеренту сыпят предложения переходить на прямых конкурентов типа спотифай или гугль/самсунг музыку

Где-то тут была мысль, мол на geektimes нельзя ничего плохого против Apple сказать, мол сразу адепты заклюют. Но видимо он ошибался, достаточно просто сказать «У меня все файлы удалились, виновата Apple, у них все через одно место» и даже не предоставив ниодного пруфа этого будет достаточно, а все кто пытается логично рассуждать будет заминусован

Нет, Apple Music не удаляет файлы с вашего диска — пока вы сами не удалите их

Сам ничего не удаляет, целый пост об этом

Нет, Apple Music не удаляет файлы с вашего диска — пока вы сами не удалите их

В оригинальной записи много недосказанностей и дыр. Потому что он утверждает, что его файлы были удалены безвозвратно, хотя четко написано, что Apple Music:

The original files aren't changed.

Более того, я точно так же добавил файлы в itunes после того как подключил Apple Music, и все файлы до сих пор лежат на своих местах на диске

Это сколько же раз надо нажать, что-бы удалить 200гб?

Достаточно делать это систематически, и не обязательно по одному файлу за раз (wav весят не мало)

Нет, Apple Music не удаляет файлы с вашего диска — пока вы сами не удалите их

В посте как раз говорится от отсутствии самостоятельности у софта, сам iTunes не удаляет без подтверждения