Roman K

Плохое вы время выбрали для вкатывания, сейчас джунов стало сильно больше, а спроса на них сильно меньше. Вам придётся конкурировать с толпой молодняка, готовых продолжительное время работать за еду, среди которых будет ещё и немало тех, кто не искал лёгких путей.

arr = [ { 'id': k, **v } for k, v in dct.items() ]

NoSQL а рекомендуют многие, говорят бистре чем SQL

Производительность можно оценить только в конкретном сценарии использования, который будет уникален для каждого проекта. Заявления про скорость без контекста нужно оценивать как пустословие и хайпожорство.

сейчас проект работает на Postgresql

Его хватает и "Мой склад", и "Сберу" и многим другим, до чьих нагрузок вам добираться ещё годы, даже если у вас всё пойдёт замечательно.

СУБД решает следующие проблемы:
1. Сетевой доступ к данным.
СУБД позволяет хранить данные на отдельном сервере.
Файлы - нет.

2. Эффективное хранение данных.
Большинство СУБД хранит данные в двоичном виде, что более эффективно и удобно для компьютера.
Файлы - нет.

3. Конкурентный доступ к данным.
СУБД позволяет работать с данными одновременно разными клиентами. И это не приведёт к непредсказуемым проблемам.
Файлы - нет.

4. Индексирование данных для эффективного поиска.
СУБД сама создаёт некоторые простые индексы и даёт возможность создать новые, чтобы поиск был быстрым. Файлы - нет.

5. Горизонтальное масштабирование.
СУБД позволяет тебе поднять несколько экземпляров базы данных не скольких серверах, и распределить между ними нагрузку.
Файлы - нет.

6. Контроль целостности.
СУБД гарантирует, что твои данные всегда будут читаемыми. У тебя никогда не возникнет ошибка "Invalid JSON".
В файлах таких гарантий нет.

7. Удобный интерфейс.
СУБД предлагает тебе удобный API для выполнения различных запросов на поиск и изменение данных.
Файлы такой интерфейс не дают.

8. Удобное администрирование.
СУБД имеет также интерфейс для отслеживания своего состояния и настройки под ситуацию.
Имеется множество инструментов для профилирования производительности БД и бэкапов.
Файлы ты никак не сможет администрировать.

Естественно, все эти проблемы ты, теоретически, сможешь решить самостоятельно. Но тогда у тебя в результате получится новая СУБД, а не просто голые json-файлы.

Что за игра? Может у вас монитор 60гц. Игра может ограничивать fps именно до частоты монитора. Т.к. выше fps нет смысла гнать.

На хабре есть статья посмотри https://habr.com/ru/post/142818/

Ты всё в кучу смешал. При чем тут Фурье? Это совсем другое преобразование и смысл его другой.

Где в этом уравнение передается информация про цвет или яркость, пикселя?

Никакая яркость пикселя тебе не нужна. Фильтр применяется последовательно к каждому цветовому каналу отдельно. RGB, CMY рассматриваются как 3д поверхности где высота поверхности равна значению канала.
Все вычисления лучше нормировать к диапазону вещественных чисел от 0 до 1 а когда все расчеты закончены - обратно приводить к RGB(8:8:8) например.

В компьютерной графике есть понятие матричных фильтров. Это - самые простые фильтры в смысле ресурсов. И самые общие. Потому что любой фильтр отличается просто размером матрицы и коеффициентами.

Конвейер такой.
1) Определяешь размер матрицы (допустим 15 на 15)
2) Инициализируешь матрицу по любой формуле. Например если все закрасить константой - то будет блур но не красивый с квадратрыми облаками в результате на картинке. Для гаусса - берешь эту формулу и подгоняешь чтобы в центре матрицы был максимум. Матрциа должна быть нормирована так чтобы в сумме не менять энергию всех пикселов которые попадают в квадрат 15 на 15. Подумай сам над этим. Гаусс также параметризуется средним квадратическим отклонением. Это скорее всего параметр сигма в формуле. Чем оно больше - тем размытее картинка. Но делать сигму больше чем 7.5 нет смысла при таком размере.

2) Матрица применяется к каждому цветовому каналу изображения по принципу перемножисть каждое на каждое и сложить. Пиксели перемножаются на матрицу. Результат всего записывается в центральный пиксель. И так далее.

3) На краях изображения будет баг. Потому что матрица вылезает за края. Картинки. Ты должен придумать как красить несуществующие пиксели. Можно красить в какой-то средний близкий цвет по расстоянию.

4) Обычно матричный фильтр работает медленно. Есть оптимизации на низком уровне. В основном - перписывание на длинных командах типа SSE/AVX. И разбиение картинки на полоски с предварительным расчетом умножений. Но это работет для малых матриц. И надо учитывать влияние и размер кешей. Тоесть цифры которые будут получены на 1 конфигурации железа могут сильно отличатсья от другой.

Решение вашей задачи:
0) изучите в документации какие виды полей бывают у Sqlite
1) на основе полученных знаний примите решение в каком формате будет столбец для DateTime
2) изучите модуль datetime
3) на основе полученных знаний выберите метод с помощью, которого преобразуете данные из Sqlite в объект datetime
4) выполните сравнение больше-меньше

"Нет времени, кроме сейчас
И нет движения, кроме вперед".
Лучшее время для усвоения новой информации - это то, которое ты потратил на усвоение новой информации.
А не на дебильные вопросы на Тостере.

https://qna.habr.com/q/1129136

Если воспользоваться поиском по этому ресурсу, то найдёте множество подобных вопросов, где про подводные камни уже отвечали. Все такие курсы - это инфоциганство и разводилово, которые пользу приносят только их авторам. В лучшем случае вам за ваши же деньги зачитают учебник, а потом продадут какой-нибудь галере на выполнение предельно тупой и утомительной работы, где рассчитывать на профессиональный и карьерный рост будет просто невозможно.