MishaXXL

Как не будет хватать производительности, можно будет задуматься. Но 300 это вообще не объем

С того количества, на котором планировщик решит применять индекс, а это зависит от множества переменчивых факторов. Поэтому при проектировании БД нужно задумывать о сценариях её использования, а не о конкретных количествах строк.

С какого количества записей индексация имеет смысл?

С того момента, когда планировщик начал показывать приличную разницу, как только получаете прирост - используйте индексацию, не получаете - не используйте.

Сделал выборку по определенному имени, вышло 75-90 мсек.
SELECT name FROM users WHERE name='Mike';
Добавил индекс CREATE INDEX name_idx ON users (name);
Выборка так и осталась в пределах 75-85 мсек.

Вы сами задали вопрос и сразу же ответили на него...

React.MouseEvent - это события реакта, их нельзя передавать в addEventListener, только в ноды реакта.
Event - это наиболее обобщенный тип события.
Вам нужен тип MouseEvent, в нём будет соответствующее свойство.
Ну и сам element должен иметь тип HTMLElement или производные по идее.

Ну так твой касперский и удалил её..
отключи антивирь, перекачай и потом запускай.
nnmclub .to - достаточно надежный сайт, как и rutracker org. хотя факапы конечно бывают..

UDPATE posts SET theme = 'IT' WHERE theme = 'it'

Это противоречит самой логике mutation. Напиши builder.query вместо этого.

Универсальное решение:

const toKeys = Object.keys as <T extends object>(obj: T) => (keyof T)[];

const ENTITIY_LIST = toKeys(ENTITIES)

Решение на раз:

const ENTITIY_LIST = Object.keys(ENTITIES) as (keyof typeof ENTITIES)[]

Моргает он потому, что в момент отрисовки старый уже удален, а новый еще не отрисован. Варианты решения:
- Убедиться точно, что новый контент загружен и лишь затем его выводить. Если контент будет слишком тяжелый для устройства клиента, то этот метод не сработает, т.к. устройству еще понадобится время для его рендера, т.е. моргание будет заметно.
- Добавить некий loading в место, где ожидается появление новых данных.

Как вариант, вместо пустого дива:

<section>
    <div ref={tables} className={style.tableWrapper}>
        {isLoading ? createTable(currentTable) : createTable(table)}
    </div>
</section>

Собственно, ответ я вам уже давал в предыдущем вашем вопросе и он все тот же: согласно спецификациям протокола - там все очень детально расписано, что посылает клиент, что и когда отвечает сервер. Вы соответствующий раздел прочитали? Какая именно у вас с ним сложность?

Сокет и веб-сокеты - это разные вещи. Сокет - это системный интерфейс, а веб-сокеты - это протокол поверх TCP-IP сетевого соединения, а на уровне системы все соединения создаются через интерфейс под названием "Сокет". Так что либо вам на сервере надо использовать не сокет-сервер, а веб-сокет сервер, либо на клиенте подключаться используя сокет, а не веб-сокет. Спецификации веб-сокет протокола находятся здесь: https://datatracker.ietf.org/doc/html/rfc6455

Это пароль от суперпользователя postgres, а не рута. Никакого рута внутри Постгреса по умолчанию нет.

psql -U postgres

Вариант 1

# Шаблон
psql -h <hostname> -p <port> -U <username> -d <database>

# Подключение
psql -h localhost -p 5432 -U postgres -d postgres

Вариант 2

# Шаблон
psql postgresql://<username>:<password>@<hostname>:<port>/<database>

# Подключение
psql postgresql://postgres:postgres@localhost:5432/postgres

супермозговывертный вызов можно сократить до
console[level].apply(console, argsWithFormat)

console[level] - некая функция из консоли, например, console.error. Но в IE9 у неё нет apply, и вызов через точку не сработает. Потому берется стандартный Function.prototype.apply и вызывается через call, так что console[level] станет для него как this (как то, что перед точкой), а остальное - аргументами.

А как описывается апишка, когда я хочу добавить вариант поиска по совпадениям с начала строки?

Начинается на max, на max или vasya:

api/users/search?name=max&startsWith=true
api/users/search?name=max|vasya&startsWith=true

Оканчивается, содержит или похоже:

api/users/search?name=max&endsWith=true
api/users/search?name=max&contains=true
api/users/search?name=max&fuzzy=true

Взято как база из Java, C#, JS, Python, в которых присутствуют аналогичные методы (как минимум startsWith и endsWith) при проверке расположения значения в строке.

Одинарная кавычка экранируется дополнительной одинарной кавычкой. Пример SQL здесь

Потому что строки обрамляются одиночной кавычкой, а значит одиночные кавычки внутри строки надо экранировать.

text и varchar - это одно и то же на уровне реализации postgresql.

varchar с каким-то разумным ограничением (не бессмысленный взятый с потолка 255 везде, а разумный для этого конкретного поля) тем не менее смысл имеет: куда проще найти ошибку в месте записи данных, чем потом искать, откуда в поле обычно содержащем до 30 символов взялось 10 мегабайт текста (история из практики, да)

Про char ограничусь цитатой письма Tom Lane

Type character(N) is a hangover from the days of punched cards. Don't use it.

Просто забудьте про такой тип данных. Он не только бесполезен, но и вреден.

Судя по этой статье можно всегда использовать TEXT вместо CHAR(N) и VARCHAR(N), т.к. производительность особо не страдает.

А если самому пойти в документацию, то можно увидеть следующее:

There is no performance difference among these three types, apart from increased storage space when using the blank-padded type, and a few extra CPU cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, there is no such advantage in PostgreSQL; in fact character(n) is usually the slowest of the three because of its additional storage costs. In most situations text or character varying should be used instead.

Т.е. в производительности разницы нет - только в стоимости хранения. (в отличие от других СУБД)

Читайте задачу правильно.

All numbers are equal except for one.

Все числа одинаковые, кроме одного.

It’s guaranteed that array contains at least 3 numbers.

Гарантируется, что в массиве минимум 3 числа.
Отсюда и такие решения.