Как исправить замедление запросов в PostgreSQL?

Для начала посмотрите в графики мониторинга что именно растёт. И как именно. Интересны io latency на чтение/запись, CPU, график длительности транзакции и график среднего выполнения запросов. График чекпойнтов, кстати.

Почему не делается update в цикле foreach?

прочитать любую заметку по самым основам SQL и познакомиться с where

Помощь в расшифровки логов postgresql?

Изучайте документацию к вашей библиотеке. Видимо у вас выключены prepared statements. Я не питонщик.
Какой из двух протоколов использовать для запроса - решение исключительно клиентской стороны. Базе без разницы.

Подойдут ли web-технологии для нагруженной медицинской системы?

Большое количество данных - это сколько в террабайтах?

Зачем делают ID в формате sha1?

Ну то есть думаете что угадаете как надо шардироваться и считаете что это нужно не через 10 лет плавного роста - пожалуйста, закладывайтесь. И постоянно тестируйте что вы действительно можете шардироваться по этому признаку, а не только когда-то давно думали об этом.
Зачем вам хранить для этого uuid - всё равно не понимаю.

Ну и раз закладываетесь на рост - то сделайте для начала хотя бы градацию запросов на rw, ro-fast, ro-slow. Пригодится ходить на реплику.

Зачем делают ID в формате sha1?

auoa16,

искать нужный шард можно по проверенной и многими любимой схеме - вычисляем хеш от логина/телефона -> берём остаток по модулю на количество шардов -> получили нужный шард.

Пришло время добавить новый шард. Действия? Перебалансируем всё? А если не хотим даунтайм на перебалансирование - то требуем места на дисках вдвое больше? Сотня террабайт SSD штука немного не дешёвая. Результат деления-то поменялся, разъехались почти все данные.

Вопрос номер следующий:

Сессий никаких не надо

Как передаёте логин при последующих запросах? После авторизации?

И, главное, - если считаем хэш от логина - зачем вам uuid или хэш первичным ключом? Зачем вам вообще его хранить? Вы по нему вовсе не ищете, вы его вычисляете от логина и так понимаете куда с этим логином идти.

Я только не совсем понимаю, почему вы говорите только о количестве регистраций

Потому что вы упустили что я говорю про отдельную базу для авторизации. Логин, пароль, ссылка на шард. Пишется эта база только при регистрации и столь же редком изменении паролей.
Гранулярные миграции по шардам, элементарный контроль уникальности. И почему-то опять никакой пользы от uuid ни для первичного ключа ни как ключа партицирования. Удивительно.

напомнили об интереснейшем проекте такой же жертвы хайпа на хайлоад: чатилка в соцсети. 12 шардов, 30 тысяч запросов в секунду, рост на террабайт данных месяца за 2-3. И всё ради... 100 сообщений в чате. В сутки. Production, ага.

а если взлетит то что вы будете делать, когда количество запросов которое можно обработать упрется в самую мощную конфигурацию железа?

Фокус в том, что упрётесь раньше и будете упираться регулярно в разные места. Задолго до того как поставите даже второй шард. А там окажется что данные чуть ли не с запуска проекта уже сильно связанные и легко шардироваться всё равно не можете. Или что шардировать надо было вовсе по другому признаку.

Зачем делают ID в формате sha1?

А на счет "пихают в varchar(255)" - это да, катастрофа, если честно не думаю, что в продакшне такие случаи есть или их очень много, уж очень это грубая ошибка.

Именно в продакшене, в разных несвязанных между собой проектах, и при том не в магазине для кошек в маленьком городе - туда DBA не требуются.
Наиболее распространённый ответ - а наша orm умеет только так. А зачем вообще uuid делают и сами не могут объяснить, так нынче модно.

Обычным сиквенсом, генерирующим uuid?

Обычным bigint.

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

Вот отсюда и давайте смотреть.
Изначально планируем шардироваться по useruid? Ок, допустим.
Well, а как? На входе у вас есть login (или почта или что вы там решили использовать) и пароль. После входа - можете использовать любой произвольный идентификатор, хоть сразу номер шарда и запомнить в сессии. Авторизацию делаем сканированием по всем шардам? А регистрацию? race condition на уникальности логина по распределённой системе?
И потому прикручивается поверх что-то дальше. Например отдельную базу под авторизацию. А почему бы в ней и не хранить сразу ссылку на шард? И сразу кардинально упрощается миграция пользователей по шардам, хоть отдельного пользователя переносить на выделенный шард. Откуда у вас столько регистраций в секунду, чтобы с этим не справилась одна мастер-база с данными регистраций и N читающих реплик?

Зачем делают ID в формате sha1?

Вряд ли на ровном месте люди себе головняки создают.

Да запросто и постоянно изобретают приключения там где ни малейшего повода для этого нет. Без вменяемой аргументации.
Вон как выше в точности: есть один проект, где это оказалось полезно. Давайте не будем думать что это совершенно не про наш проект, а тупо сделаем так же, ведь те ребята так сделали и вон как выросли.
Самое интересное происходит когда нет осмысленной причины даже не использовать штатный в субд тип данных под uuid, а пихают в varchar(255) какой-нибудь или сразу в text.

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

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

Раз 5 перечитал я все равно не понял. Можете пожалуйста чуть более подробно сказать, что имеете в виду?

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

Зачем делают ID в формате sha1?

может народ использует это как правило хорошего тона, чтобы привыкнуть и использовать уже на крупных проектах

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

за счетчик айдишников обычно большая конкуренция в кластере. Как это вот все синхрогизировать, чтобы две записи с одинаковым ключом не сгенерились?

Вы спрашивали именно про id в базе. База его и должна генерировать. Соответственно retry - откуда? его просто не может появиться.
А упереться в производительность выдачи чисел из сиквенса - ну, это сложно. Очень.

Зачем делают ID в формате sha1?

Я описал из практики что вы реально получите если будете использовать:
- uuid в text/char/varchar
- sha, md5 или ещё что из хэшей в text/char/varchar
- uuid в специальном для этого типе данных

вместо последовательных int4 или int8. При том int8 вы не исчерпаете никогда (просто посчитайте сколько и как долго вам надо писать чтобы его исчерпать)

use-case нужен довольно редкий. И большое заблуждение будет начитаться разных highload и решить, что уж для ваших 1к rps к 100гб базе точно нужно шардирование на десятки хостов

Такие временные метки бывают?

Николай Демидовец, значит займитесь reverse engineering - достаньте штук 10 пар как это значение хранится и как выводится. Затем ищите между ними взаимосвязь. А то может вам примерно 1974-03-09 20:57:25 и нужно.

Такие временные метки бывают?

Это как бы вам вопрос. Найдите в проекте использующем эту базу как этот формат кодируется при форматировании запроса и/или при выводе из этой таблицы пользователю.

Что делать если увольняют с работы(IT компания. Скорее всего по статье за несоответствие занимаемой должности)?

Мне что отвечать новым работодателям почему 2 месяца?

Компания не прошла испытательный срок. Не понравилось у них.
Это 100% корректный ответ. Испытательный срок не только про соответствие должности вами но и про то, устраивает ли работодатель вас.

Не запускается PostgreSQL после сбоя питания. Как заставить работать?

опять fsync = off?

В каком формате хранить значения nanoseconds?

не подойдёт. У timestamp в postgresql точность микросекундная.

Возможно self-union заменить на self-join?

where id in (select .... )
?

Вывод из БД значений с текущей датой?

Вячеслав, выражение "функция(поле) оператор операнд" не может использовать индекс по этому полю. А требует индекс именно по "функция(поле)". В 8.0.13 поддержка функциональных индексов появилась. До того - generated virtual column и индекс по этому псевдополю. Ещё раньше - обычное поле с индексом под результат вычисления функции и его запись через триггера.

И во всех случаях это всё равно должен быть отдельный индекс именно под это вычисляемое выражение. А каждый индекс - это не бесплатно.

Поэтому where date >= curdate() and date < curdate() + interval 1 day

Вывод из БД значений с текущей датой?

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

Можно и полностью на SQL сделать. И нормально, а не через date_format. Вы ведь знаете, какой для условия DATE_FORMAT(`date`, '%Y-%m-%d') нужен индекс? Нет, и близко не по date.

Как в запросе на PostgreSQL добавлять только уникальные значения?

INSERT INTO plans (name, holl_id, status, start_date, end_date,
       review_start_date, review_end_date, approval_date, expiration_date, created_at, updated_at)
       VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11) 
ON CONFLICT (name) DO NOTHING
RETURNING id;

Как проще всего и надежно хешировать пароль в PHP 5.3.5?

Konata Izumi, археолог - это 5.3.29. 5.3.5 - это мазохист.