и состоят в основном из радиатора: https://tiscom.ru/ssd/intelr-ssd-dc-p4500-0

На M.2 nvme ssd пока массовое радиаторы не вешают, вроде :)

поближе к топовым конфигам это уже норма: https://www.asus.com/Motherboards-Components/Motherboards/All-series/Prime-TRX40-Pro/

а так да, для стрелялок охлаждать не надо ничего

Это материнка, а не сам SSD. На матерях-то, да, радиаторы под SSD есть уже давно.

а по стандарту m2 ты не можешь сделать радиатор частью ссд, он тогда в габариты не впишется - только частью материнки/корпуса/шасси

С распространением Direct Storage, я думаю, вполне потребуется :)

Наверное, если пересчитать в джоулях на доставленный байт, то поди можно будет сделать вывод, что SSD почти не греются.

Можешь сделать исследование типа того. что ты делал с аккумами :)

До сих пор припоминают. Это было десять лет назад.

А что, неплохое вышло :)

Не, бестолковая затея: в интернете все пишут про температуру в 50 градусов в простое. Никаких джоулей на байт тут не посчитаешь — на ноль нельзя делить.

Там дырки маленькие, вот электроны протискиваться должны и от трения нагревается 😂

Привет, такой вопрос. Если есть составной индекс по полям А и Б ( в таком же порядке построен индекс ), то есть смысл делать отдельно индекс по полю Б? Если есть смысл то в каких случаях?

Имеет, но это зависит от запросов

"Порядок полей
Порядок полей в индексе весьма важен с точки зрения использования индексов. Решая вопрос об использовании индекса, сервер должен обработать его от первого поля до последнего. Это означает, что оптимизатор запросов может счесть индексы приемлемыми только тогда, когда нужные ему поля располагаются выше (следуют ранее) полей, которые ему не требуются (для выполнения запроса). Если какие-либо незначимые в плане выполнения запроса поля находятся выше нужных оптимизатору запросов полей, то индекс будет проигнорирован за ненадобностью.
Планируя создание индексов, вам следует лишь поместить в вершину индекса те поля, которые часто используются в запросах. Даже одно поле, не являющееся частью необходимых оптимизатору запросов полей, заставит его проигнорировать индекс."
http://www.sqlbooks.ru/readarticle.aspx?part=01&file=querytuning01#:~:text=%D0%98%D0%BD%D0%B4%D0%B5%D0%BA%D1%81%20%2D%20%D1%8D%D1%82%D0%BE%20%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1%20%D1%80%D0%B5%D0%BB%D1%8F%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%BE%D0%B9%20%D0%B1%D0%B0%D0%B7%D1%8B,%D1%83%D0%BA%D0%B0%D0%B7%D0%B0%D1%82%D0%B5%D0%BB%D0%B5%D0%B9%20%D0%BD%D0%B0%20%D1%84%D0%B0%D0%BA%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5%20%D0%BC%D0%B5%D1%81%D1%82%D0%BE%D0%BF%D0%BE%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5%20%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85.

В случае, если планируются запросы WHERE Б = ... / ORDER BY Б.

Составной индекс по А и Б — это как сортировка по имени и фамилии. Она тебе поможет найти Василия и Василия Иванова, но не Иванова.

Спасибо!

коллеги, подскажите плз..
есть такая функция extract(second from timestamp table.column)
но проблема в том, что timestamp так же является названием поля в одной из таблиц, и postgres думает, что я обращаюсь к нему.. как можно указать, что timestamp просто выражение в конструкции функции second from timestamp а не колонка в таблице?