Сначала "Подойдут любые варианты", потом чтобы пользователи могли сами ставить. А потом какие неожиданные требования добавятся? Портировать на sqlite?
Вычислительную производительность компилируемого C достать можно только другим C. Других вариантов нет.
join 49 таблиц - это факториал от 49 вариантов порядка объединения. Здесь один только планировщик будет думать над задачей дольше, чем скомпилированный C.
И уж тем более человек в попытке понять, что же вы там пытаетесь посчитать.
spacenear, ремарка про https относилась именно и только к набиранию запроса полностью руками фактически на голых сокетах. Просто потому что шифрование руками набирать неудобно.
Что угодно чуть-чуть повыше уровнем, что возьмёт tls уровень на себя - и можно снова общаться с сервером даже руками набирая запросы.
А уж если взять что-то для этого предназначенное как тот же curl - то вообще элементарно.
spacenear, берёте curl и делаете абсолютно любой запрос. Да хоть руками вбить через netcat или telnet, если там простой http, а не https. Да, так можно. На любой url можно прислать любой запрос и только бекенда дело, что при этом случится и как понимать, что запрос пришёл ошибочный.
GutOf, а решений всегда может быть много. В этом как раз и есть задача разработчика - угадать вектор дальнейшего развития и использования системы и соответственно этому выбрать решение.
Анатолий Сидоров, да, RAM.
Для RAM вроде ничего лучше memtest (на сутки) пока не было
Диски - вопрос интереснее. Наверное badblocks в пишущем режиме будет достаточно. Но сначала память проверить.
Возьмите какое-нибудь другое float число схожего порядка и получите другой хвост за значащими разрядами. Этот хвост не имеет значения.
т.е. 10799141199215210000 хранится как 1.07991411992152E+19?
Сюрприз: нет. В мантиссе (52 бита всё-таки) для вашего числа хранится что-то вроде 1708452349166847 и читается способом вроде вот такого: +1 * pow(2, 1086-1023) * 1.1708452349166847
Потому что формат с двоичным основанием.
Читайте IEEE 754 или его многочисленные объяснения, пригодится однозначно, хотя бы чтобы не пытаться в нём деньги считать.
Ещё раз напишу: нет в php типа данных long. А если говорить в терминах C - то для long гарантированы минимум 32 бита, а не 64.
Если вы пользуетесь терминологией java - то я вас просто не пойму, т.к. не знаком с особенностями этого языка (кроме склонности jvm использовать много памяти).
В PHP при числовом переполнении будет осуществлено приведение типа до float, т.к. терять значение считается языком более нежелательным, чем потеря точности.
Какая версия PHP, операционная система и разрядность ОС?
Как минимум в PHP нет типа данных long. Есть только int, размер которого зависит от факторов указанных строкой выше.
Начните с рисования структуры сети. При том не со слов кого-либо, а проверяя, что так в действительности и скоммутированы линии и настроено оборудование.
А может и вообще с теории сетей и маршрутизации. - потому что описания "дают доступ в интернет" и "интернет падает во школе" никуда не годится. Как дают? Что после этого происходит в сети? Где пакеты пропадают?
Вот loose index scan вручную делать надо только с пониманием, что, где и как именно хотим достать и какие исходя из этого индексы требуются. Т.е. сначала решаем, по каким индексам будет запрос работать хорошо и потом пишем запрос именно для этого поведения, а не как обычно, когда сначала пишется запрос для получения нужных данных и потом смотрим на реальных данные какие для него нужны индексы.
Обычно в такие дебри залезаем в попытке ускорить то что уже есть и где возможно переписать запрос радикально. Без индекса, под который запрос строился - результат наверняка будет крайне плачевным. Рекурсивные запросы вообще неплохо могут выстрелить в ногу.
Кстати, вот презентация по нескольким переосмыслениям запросов от моего коллеги и руководителя: https://pgday.ru/presentation/232/5964945ea4142.pdf (запись доклада конференции в свободном доступе к сожалению не опубликовано)
в общем случае выражение в индексе должно совпадать с тем, что пишем в запросе. Для красоты можно сделать immutable language sql хранимку с jsonb и именем параметра на входе и числом на выходе.
Для фильтров каталога вроде серебряной пули не сделали ещё
По вашему плану очевидно, что вы перенесли запрос в свою исходную задачу некорректно. У вас есть некий фильтр country, отсутствующий в постановке вопроса и напрочь ломающий весь механизм loose index scan.
Алексей Черемисин, использовать базу в качестве калькулятора предлагаете здесь как раз вы - вычитывать всю таблицу вместо простого index scan.
Вы могли бы такими "аргументами" попытаться убедить рядового разработчика, но не пытайтесь таким образом в чём-то убедить специализирующегося на этой СУБД DBA, так вы лишь доказали, что не умеете и потому боитесь использовать свой postgresql.
У меня нет настроения ковырять очередную глупость очередного orm. Возможно вам не нужны в query builder ни джойны ни distinct, а связанные данные подгружаются отдельно за кадром через известную "N+1 query problem".
Алексей Черемисин, ну позиция так позиция. Не буду тогда больше ничего писать. Попечалюсь только вновь, что таких панически боящихся СУБД людей почему-то много - как работал 7 лет разработчиком, так и после смены деятельности на DBA не стал лучше понимать этот странный феномен боязни субд. Зато явно без работы не останусь, хоть и с постоянным фейспалмом от результирующих чудес такой "позиции".
Вычислительную производительность компилируемого C достать можно только другим C. Других вариантов нет.
join 49 таблиц - это факториал от 49 вариантов порядка объединения. Здесь один только планировщик будет думать над задачей дольше, чем скомпилированный C.
И уж тем более человек в попытке понять, что же вы там пытаетесь посчитать.