Вы делаете выводы на основе абсолютно ложных данных.
Решение капчи требует 40 - 90 секунд, так что, независимо от async, все вменяемые люди выносят ожидание в крон/очереди/вебхуки: один фиг ни пользователь, ни браузер ответа столько ждать не станут.
Если зайти на packagist, то «модулей» для одной только 2captcha найдется 17 штук. Хз нафига они сдались - с нуля там строчек 15 - 30 кода, а подключение и настройка обёртки порядка 10.
К закрытому коду имеет доступ куча джунов и субподрядчиков, их код далеко не всегда хоть кто-то ревьюит, а уж чтобы ревью делали спецы по безопасности... не будем о грустном.
Глянул как-то на младшие ресторанные посудомойки и удивился, что они дешевле на уровне средних-дорогих домашних, то есть ценник не особо конский. И моют за несколько минут, а не пару-тройку часов.
А смысл? Быстрые vs экономичные ядра, возможность ненадолго задрать частоту одного или пары ядер, отличия в архитектуре изрядно портят прикидки по частоте.
В нём любое изменение создаёт новую версию (читай - копию) строки. Даже UPDATE test_data_varchar_with_update SET height = height + 1 (изменение значения в int колонке) удвоит размер занимаемого места, а потом придёт дефрагментатор (автовакуум) и почистит мусор.
Погонял немного запросы, получил такое:
CREATE TABLE test_data_varchar_with_update (
id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY ,
id_pointer varchar(100) DEFAULT NULL,
name text NOT NULL,
width int NOT NULL DEFAULT 0,
height int NOT NULL DEFAULT 0
)WITH (autovacuum_enabled=off);
insert into test_data_varchar_with_update (id_pointer, name, width, height)
select random()::text, round(random() * 100000)::text, (random() * 20000)::int, generate_series(1, 1000000);
create table t2 as select * from test_data_varchar_with_update;
alter table t2 add primary key (id);
UPDATE test_data_varchar_with_update SET height = (random() * 1000000)::int;
UPDATE test_data_varchar_with_update SET name = substr(repeat(md5(random()::text), 8), 0, 10 + (random() * 240)::int);
UPDATE test_data_varchar_with_update SET name = substr(repeat(md5(random()::text), 8), 0, 10 + (random() * 240)::int);
select pg_size_pretty(pg_relation_size('t2')); // 72 MB
select pg_size_pretty(pg_relation_size('test_data_varchar_with_update')); //526 MB
explain analyze select * from test_data_varchar_with_update where id in (select (random()*100000)::int as id from generate_series(1, 1000));
explain analyze select * from t2 where id in (select (random()*100000)::int as id from generate_series(1, 1000));
Последние два стартуют с 70 мс vs 20 мс, но после 5 - 10 запросов устаканивается на 15 - 30 мс vs 10 - 15 мс.
Да, в постгресе есть стандартное расширение pg_trgm (триграммы)
select * from place_europe_spain where name like '%Sil%';
create index test2 on place_europe_spain USING GIN (name gin_trgm_ops);
+----------------------------------------------------------------------------------------------------------------------+
|QUERY PLAN |
+----------------------------------------------------------------------------------------------------------------------+
|Seq Scan on place_europe_spain (cost=0.00..11652.56 rows=746 width=1535) (actual time=4.303..46.607 rows=152 loops=1)|
| Filter: (name ~~ '%Sil%'::text) |
| Rows Removed by Filter: 81253 |
|Planning Time: 0.224 ms |
|Execution Time: 46.679 ms |
+----------------------------------------------------------------------------------------------------------------------+
+-----------------------------------------------------------------------------------------------------------------------------+
|QUERY PLAN |
+-----------------------------------------------------------------------------------------------------------------------------+
|Bitmap Heap Scan on place_europe_spain (cost=17.78..2347.91 rows=746 width=1535) (actual time=0.288..1.882 rows=152 loops=1)|
| Recheck Cond: (name ~~ '%Sil%'::text) |
| Rows Removed by Index Recheck: 175 |
| Heap Blocks: exact=294 |
| -> Bitmap Index Scan on test2 (cost=0.00..17.59 rows=746 width=0) (actual time=0.223..0.224 rows=327 loops=1) |
| Index Cond: (name ~~ '%Sil%'::text) |
|Planning Time: 0.333 ms |
|Execution Time: 1.993 ms |
+-----------------------------------------------------------------------------------------------------------------------------+
На строках в пару символов скорее всего не будет использоваться.
Именно для like '%%' коробочную поддержку завезли в 12 или 13 версии, но в форме регулярного выражения name ~ 'Si' в 9.6 из 2016 года уже работало, а в форме name ~~ '%Si%' вероятно работало аж в 8.3 из 2008 года.
Если устроит поиск по префиксу слов, независимо от места самого слова в строке, то есть полнотекстовый поиск to_tsquery('russian', 'Sa:*'). Тут магия в :*., сам индекс намного компактнее триграммного, можно ещё ускорить (1) сохраняя результирующий to_tsvector (2) добавив расширение на индекс RUM.
create index test3 on place_europe_spain USING GIN (to_tsvector('simple', name));
explain analyze select * from place_europe_spain where to_tsvector('simple', name) @@ to_tsquery('simple', 'S:*');
+------------------------------------------------------------------------------------------------------------------------------+
|QUERY PLAN |
+------------------------------------------------------------------------------------------------------------------------------+
|Bitmap Heap Scan on place_europe_spain (cost=32.62..4799.94 rows=1628 width=1535) (actual time=0.164..0.668 rows=152 loops=1)|
| Recheck Cond: (to_tsvector('simple'::regconfig, name) @@ '''sil'':*'::tsquery) |
| Heap Blocks: exact=132 |
| -> Bitmap Index Scan on test3 (cost=0.00..32.21 rows=1628 width=0) (actual time=0.110..0.111 rows=152 loops=1) |
| Index Cond: (to_tsvector('simple'::regconfig, name) @@ '''sil'':*'::tsquery) |
|Planning Time: 0.291 ms |
|Execution Time: 0.802 ms |
+------------------------------------------------------------------------------------------------------------------------------+
Нормально переваривает двухбуквенные префиксы (3-5 мс) и хоть немного, но ускоряет поиск по одной букве (10-30 мс).
На практике видел только один запрос на котором мускуль был сильно быстрее: UPSERT одной строки во времена Postgres 9.6 или 10. В среднем же постгрес позволяет ускориться в 1,5 - 2 раза без особых усилий, а если активно использовать массивы/полнотекстовый поиск/частичные и функциональные индексы, то местами и в 10-100 раз ускориться можно.
В мускуле даже любимый всеми like '%text%' индексы не использует и чёрт знает когда сможет.
и не создает отдельных процессов для каждого подключения
Какая разница сколько процессов, если мускуль жрёт намного больше оперативки?
Похоже это чисто убунтовая обёртка над pg_upgrade / pg_ctl
Как насчёт (1) кеширования файла в ОЗУ силами ОС (2) mmap?
Вы делаете выводы на основе абсолютно ложных данных.
Решение капчи требует 40 - 90 секунд, так что, независимо от async, все вменяемые люди выносят ожидание в крон/очереди/вебхуки: один фиг ни пользователь, ни браузер ответа столько ждать не станут.
Если зайти на packagist, то «модулей» для одной только 2captcha найдется 17 штук. Хз нафига они сдались - с нуля там строчек 15 - 30 кода, а подключение и настройка обёртки порядка 10.
Авторы статьи поленились искать, в реальности их десятки или сотни, как и для питона с js.
Он и в районе 2005 года только на компе запускался.
Окей, возражений по существу не жду, благо ущербность вашего заявления много раз разобрали.
ORLY?!
он был первым, кто пошёл на третий срок
её побежали принимать сразу как только он сыграл в ящик, а жать немного начало ещё в середине его второго срока.
У неё две задачи: (1) ограничить скорость развития звёздной болезни у правителя и (2) уменьшить ущерб если правитель начнёт творить что-то не то.
В php, благодаря растущей популярности RoadRunner, тоже уже нет такой зависимости.
Фоновая обработка с веб-сервером не связана почти никак.
Или вы что-то меняли в коде очередей при переезде с апача на nginx?
А если вы про fastcgi_finish_request, то это не совсем "фоновая обработка", сервер в целом от этого не ускорится.
Неплохой послужной список, если не наврали в резюме.
Вы утверждаете, что они исключительно идейные, а не просто «наёмники»? А основания для таких утверждений есть?
Но ведь yum - команда из Redhat, где JIT выключен, о результатах проверки в Debian без докера - ни слова.
К закрытому коду имеет доступ куча джунов и субподрядчиков, их код далеко не всегда хоть кто-то ревьюит, а уж чтобы ревью делали спецы по безопасности... не будем о грустном.
MySQL вот блокировочник и живёт себе, не особо тужит. Хоть я и «голосую ногами» за переход постгрес.
Глянул как-то на младшие ресторанные посудомойки и удивился, что они дешевле на уровне средних-дорогих домашних, то есть ценник не особо конский. И моют за несколько минут, а не пару-тройку часов.
Новость чётко говорит, что нейросетка - в декодере. Они, условно, хотят 4k превратить в 480p, а потом через DLSS растянуть обратно в 4k.
Маломощный комп не требуется, по проверенной схеме с AVC и HEVC хотят заставить купить новую видюху с аппаратным декодером.
А смысл? Быстрые vs экономичные ядра, возможность ненадолго задрать частоту одного или пары ядер, отличия в архитектуре изрядно портят прикидки по частоте.
По части «быстрым» есть вопросы — 1.3.0 на гиговом дампе на MacBook M2 перемалывает всего лишь ~10 Мб/с сырого SQL.
Я правильно понимаю, что шаблоны компилируются заново для каждого значения?
Хотя мускуль 8.0 тоже индексы использует, но толку с них мало:
name = 'дубай'—actual time=0.061..0.072по префиксу
name like 'дубай%'—actual time=0.199..0.232name like '%дубай%'—actual time=205.801..228.952, в плане естьCovering index scanname like '%дубай%'без индексов -actual time=19.382..277.397В постгресе всё воспроизводится на 146%.
В нём любое изменение создаёт новую версию (читай - копию) строки. Даже
UPDATE test_data_varchar_with_update SET height = height + 1(изменение значения в int колонке) удвоит размер занимаемого места, а потом придёт дефрагментатор (автовакуум) и почистит мусор.Погонял немного запросы, получил такое:
Последние два стартуют с 70 мс vs 20 мс, но после 5 - 10 запросов устаканивается на 15 - 30 мс vs 10 - 15 мс.
Да, в постгресе есть стандартное расширение pg_trgm (триграммы)
На строках в пару символов скорее всего не будет использоваться.
Именно для
like '%%'коробочную поддержку завезли в 12 или 13 версии, но в форме регулярного выраженияname ~ 'Si'в 9.6 из 2016 года уже работало, а в формеname ~~ '%Si%'вероятно работало аж в 8.3 из 2008 года.Если устроит поиск по префиксу слов, независимо от места самого слова в строке, то есть полнотекстовый поиск
to_tsquery('russian', 'Sa:*'). Тут магия в:*., сам индекс намного компактнее триграммного, можно ещё ускорить (1) сохраняя результирующий to_tsvector (2) добавив расширение на индекс RUM.Нормально переваривает двухбуквенные префиксы (3-5 мс) и хоть немного, но ускоряет поиск по одной букве (10-30 мс).
Когда-то был быстрее.
На практике видел только один запрос на котором мускуль был сильно быстрее: UPSERT одной строки во времена Postgres 9.6 или 10. В среднем же постгрес позволяет ускориться в 1,5 - 2 раза без особых усилий, а если активно использовать массивы/полнотекстовый поиск/частичные и функциональные индексы, то местами и в 10-100 раз ускориться можно.
В мускуле даже любимый всеми like '%text%' индексы не использует и чёрт знает когда сможет.
Какая разница сколько процессов, если мускуль жрёт намного больше оперативки?