Посмотрите внимательно на пример parseHeaders и подставьте простейший
HTTP/1.1 200 OK
Content-Type: text/html
на вход. С array_reverse и без него результат будет правильный и не правильный. Ещё интереснее, если взять заголовки от http 301 с включенным follow location, где ^HTTP/ может быть несколько.
мне кажется размер данных (~200-300 мегабайт) делает это решение не оптимальным...
Было бы 300гб данных или неизвестный объём - да, не предлагал бы так сходу, может быть предпочтительнее что-то умеющее работать с диском. А 300мб на весь экземпляр приложения - не проблема.
А это указано в исходных данных в вопросе: есть оценка максимального объёма данных, при том, при разворачивании приложения уже заранее знаем, сколько памяти нам нужно будет под эти данные.
Ну а если же начальные ограничения задачи ошибочны - то нет ничего удивительного в том, что можно пойти в неправильную сторону.
Отдельно отмечу, что второй ответ - redis - тоже не сможет держать в памяти только горячие данные, а остальное доставать по необходимости с диска. Аналогично будет держать весь массив данных в памяти.
По-моему, это несколько замечательных школьных задач по физике:
- рассчитайте, сколько энергии необходимо потратить на разогрев воды в кружке. Объём воды в кружке, начальная температура и желаемая конечная для конкретно ваших условий
- рассчитайте объём запасённой энергии в вашем аккумуляторе (внесистемные мАч перевести во что-нибудь стандартное)
Как раз дать практическое применение этого всего массива знаний, чего так не хватает в школьных программах.
Привычка, сэр. Вот в руках один девайс, прослуживший много лет. Который работает одновременно и под хранение всевозможных данных (драйвера те же) и для загрузки пачки разных версий ОС, да ещё всякая загрузочная мелочёвка, на которую жалко целую флешку выделять (memtest банально - и не надо вспоминать, на каком дистрибьютиве он есть встроенный в лёгком доступе). Когда просто не думаешь, от чего придётся отказаться, чтобы закатать другой дистрибьютив, а берёшь и кладёшь исошку рядом.
Подписывать и переподписывать флешки? Запоминать что на какой флешке? Зачем, просто берёшь и переключаешь образ.
У меня VE-200, ещё с usb 2.0, с тех времён, когда при заказе легко было услышать "вы знаете, уже все разобрали, следующая партия будет через неделю, могу для вас зарезервировать"
Не увидел в мануале упоминаний об ограничениях pci-e режима, только про шаренный sata написано. Попробуйте аккуратно протереть контакты. Как 3.0 x4 согласно мануалу завестить должен
Хотя кому эта полоса нужна?.. Вы должны делать что-то интересное, чтобы вас волновали seqscan/seqwrite, а не random i/o, которым и до 3.0 х1 далеко ещё
Режим передачи PCI-E 3.0 x2 (985мб/с *2) вместо паспортного PCI-E 4.0 x4 (1.97гб/c * 4). То есть шина заведомо уже в 4 раза. Вполне похоже на предел шины.
ну, для начала сделайте выражения синтаксически корректными. Тогда может быть станет понятно, что вы подразумеваете под "в поле secret добавить новую функцию"
да, могли бы. Если бы не существовало частичных индексов - то сюда бы подошёл btree(status, date). Но такой индекс будет существенно больше частичного.
какие именно запросы? Что такое "разные условия"?
"where status = 'pending' order by date limit 20" и всегда только pending это совсем не то же самое, что поиск по любому статусу.
под "where file_name = ?" - полностью другая история и полностью другой индекс
По распределению данных: id уникален? А file_name? уникален? Сколько из ваших 50млн строк в каком статусе типично числятся?
Медленнее в общем случае. Треть таблицы быстрее будет прочитать seqscan'ом.
index scan'ом читать треть таблицы - это много скакать (по памяти или random i/o) сперва для индекса, потом для каждой найденной в индексе версии строки лезть в таблицу. Много беготни. Обычно база не будет использовать такой индекс.
А где вы видели, что фича появится в pg14? Я за этой темой не слежу, но и в pg15 я бы не ждал тоже. Долгострой, привлекающий очень мало внимания.
Если смотрите на Target version - то перестаньте туда смотреть. Единственная цель и причина появления этого значения - во время мартовского коммитфеста вежливо указать, что эту штуку можно отложить на потом.
Если вам интересен этот патч - прочтите ветку, скомпилируйте, протестируйте в каких-нибудь условиях, всё ли работает как ожидается. Может быть есть идеи по улучшению пользовательского взаимодействия с фичей? Большинство патчей топчутся на одном месте из-за недостатка review. Да, даже review от незнакомых с кодовой базой людей приветствуется. (пишу как контрибьютор)
покажите реальный sql запрос. Из лога базы, например, легко достаётся. По-видимому, вы конкатенируете значение напрямую в запрос и получаете from (values (63 933-339-99-97)) as p(n);
что, конечно, ничем кроме как ошибкой быть не может. Передавайте строку как строку.
