Кстати да. Сейчас есть такие как Xubuntu (XFCE) которым надо 1Гб памяти и все. Ну тоесть реально на металоломе работают. А для изучения например сетей и протоколов этого более чем достаточно. Даже интересно. Вот щас есть целое комьюнити фриков которые покупают Raspberry, Arduino, и железки более мелкие вплоть до stm-32. И что-то там кодят. Это-ж мозохисты. Но они себе там то умный дом делают. Тоже тема.
oneLEAM, такого уровня изоляции не знаю. Ну вот выше по тексту тебе предложили виртуалку. Ну не знаю. Мне было-бы не интересно. Я люблю полный доступ к железу чтоб можно было педаль в землю втопить. Виртуалка - это ограничитель. Кроме того если ты начинающий пользователь то ты даже сходу доступа к этой виртуалке не откроешь. Понимаешь разницу между nat, brigde, host e.t.c? Это будет челледж еще тот. Замкнутый круг. Ты изучаешь линукс. Ставишь на виртуалку и доста к нему нету с других машин. А нету - потому что ты изучаешь линукс. А если ты что-то тыкнул или "оно заработало" - ты еще нихрена ни линуксоид. Надо чтоб оно упало в плинтус. И ты разобрался. Поднял. Поэтому я против виртуалки в данном учебном примере. Хотя во всех других отношения виртуалка удобна конечно.
Ты можешь на бумажке нарисовать график (линия) который пройдет через нужные тебе точки.
(1,1) и (8,100) и далее как делали в школе - придумать функцию которая пройдет через эти
две точки. Там легко. Найти коэффициент наклона и сдвиг по оси Y.
После этого у тебя - готовая функция вида y = f(x) и подставляй в нее вещественные числа и все будет ок.
Да можно имя сократить. Вот эта вся эстетика "Доступно_на_складе...." она ведь самой базе не нужна.
И программисту который делает отчеты - тоже не надо. Я в таких случаях детализацию скидываю в
комментарии к солонкам. Те кто не знают - посмотрят.
create table ostatki
(
toliatty_mag decimal
);
comment on column ostatki.toliatty_mag is 'Доступно_на_складе...';
Те кто знают - им пофиг. И приложению обычно пофиг т.к. маппинг является частью кода приложения почти всегда. Ну я не видел приложений которые всегда отображают поля 1:1. Всегда есть какие-то украшения.
Vitsliputsli, ну почему-же. Оптимальное хранение информации - это архиваторы. Это тоже тема. Только формулировка другая. И мои претензии - только к формулировке задачи.
Если действовать по аналогии с base85 то можно было получить 56 бит на один пароль.
Да и кто вообще хранит пароли на сайтах? Есть же хеши. Хоть бы речь шла о key-wallets.
Скорее всего в компилляторе есть некий хардкод который если видит знакомый шаблон - включается. Типа интризик.
Но я-бы на твоём месте собирал это в отдельных функциях и наблюдал-бы ассемблерный выхлоп. Хотя-бы на уровне - меняется код или не меняется для данной функции.
Кстати обидно что в топике ты не указал компиллер. Clang? Gcc? VisualC++?
floppa322, извини а какие в бенмарке ты видишь ПУТИ исследования оптимизаций? Просто играться с типами и дождаться что вдруг на каком-то из них будет щастье? Мне кажется что это не инженерный путь.
Мне задача напоминает научпоп. В котором не хватает исходных данных. Это как помните популярную задачу о взлетающем самолёте. Тоесть ее решать на основе знаний физики - бесполезно. Это парадокс. Можно фантазировать и придумывать миры или системы отсчета где эта задача решается и где не решается.
Возможно Армянское Радио прав. И здесь мы просто не можем расплющивать планеты не оперируя сравнением бесконечностей. Это как теория пределов. Или как игры Кантора с бесконечностями. Счетными и не-счетными.
Вот. А чтоб эти бесконечности сравнивать - у нас не хватает исходных данных.
Этот вопрос идет очень глубоко. Слабая контроль над типами в Java был одним из мотиваторов например создания языка Scala. По крайней мере Мартин Одерский в своих лекциях неоднократно ссылается на сравнение контроля типов при создании коллекций.
Википедия цитирует буквально следующее
many of Scala's design decisions are aimed to address criticisms of Java.
Поэтому тема это глубокая. Я советую автору ее не трогать. Просто забить. Воспринимать Java как есть. Есть некоторая видимость контроля типов при использовании Generics. Когда компиллятор видит неверный кастинг - он предупреждает. Вот такой вариант существует на данный момент.
Сама идея создания массива списков - не очень умная идея. Если ты пошел в коллекции - то делай тогда единообразно. Делай List<List<....>>
Такое решение по крайней мере не вызывает вопросов на code-review.
Если ты используешь микс из объектов уровня language и объектов уровня jdk то ты должен
обосновать зачем. Не по причине детского любопытства.
kiddle, что у тебя в тексте? Не вижу... Там надо analyze table [table name]... А для запроса - explain select...
Это первое. И второе. Что меня смущает. Ты уверен что мы воюем именно с select?
У тебя 2 конфигурации на одной из них процесс ETL идет 20 минут а в другой - более суток.
Я здесь вижу что проблемой может быть также insert. Он зависит от многих параметров но
главное - от того destincation куда ты вставляешь 2 млн строк. Всяко тут может быть.
Проверяй эту версию.
И помни что любой SQL запрос select имеет 2 фазы. Первая фаза - это execution. Это пока висят
песочные часы. И второе это fetch - когда БД уже начинает выдавать строки на экран. Новички
часто этого не понимают и считают что им интересен только execution. А в твоей задаче
в миграции строк важны обе фазы. Поэтому твои эксперименты по select должны включать
не визуальную оценку (как только получил 1 page). А ПОЛНЫЙ подсчет всех 2 млн строк.
Это если ты хочешь играться с оптимизацией select.