Вячеслав Успенский

Записываете время выдачу (ну пусть будет created_at) и возврата(expired_at) кредита в timestamptz
второй как alter table my_table add expired_at timestamptz generated always as ( created_at + interval '3 day');

Затем ищете протухшие через select * where is_payed=false and expired_at
Ну на всидку конечно)

Довольно просто

create index my_table_index_index on my_schema.my_table using gin (cast(string_to_array(index, ', ') as int[]));

select *
from my_schema.my_table 
where string_to_array(index, ', ')::int[] @> ARRAY [1, 2, 3]::int[];

select *
from my_schema.my_table 
where cast(string_to_array(index, ', ') as int[]) @> cast(string_to_array(:param, ', ') as int[]);

Второй вариант запроса параметризованный и касты немного переделали чтобы не было проблем с параметрами.
param Должен быть строкой вида '1' или '1, 2, 3';

Кстати переделать на хранение массива можно ровно так же как тут строится индекс.

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

1. Трекер задач. Все что за его пределами, просто не существует. Он должен быть единственным каналом получения/обработки задач.
2. Самые мерзкие и противные вещи делать с утра
3. Стараться короткие задачи делать сразу же, длинные отправлять в конец списка.
4. Делегировать и ставить задачу себе на контроль результата.
5. Работать не более 8/9 часов
6. До/после работы забывать вообще все, что связано с работой. Для того, чтобы хорошо работать, нужно хорошо отдыхать.
7. Если есть возможность, наймите помошника и обучите его базовым вещам. Самое главное, научить его обращаться к вам в случае успеха/неудачи. Если он это сможет сделать без контроля, то начинайте понемногу обучать его всему, что хотя бы в теории сможете делегировать в будущем.

Как только вы таким образом наладите весь процесс, ощущение паники/каши у вас должно пройти. Эффективность возрастет и будет больше времени, сможете детально изучать бекграунд сложных задач.

Он работает во всех новых броузерах довольно давно, но не со всеми элементами. Например вы можете его использовать с th но не с tr и thead

Не переживайте, как верно подметил

Melkij

Такие конструкторы обычно адаптированы под людей, которые не знают и знать не хотят свою базу.

Как правило, любые нестандартные вещи из коробки поддерживаются чуть менее чем никак. Я бы даже сказал все, что выходит за грани примитивного. Более того в некоторых языках сами драйверы накладывают ограничения. Например PHP не умеет работать с PostgreSQL массивами, совсем. Как правило обходят это дело так ну или сразу используют jsonb

Тут происходит css-анимация через keyframe.
Вполне реально на глаз расчитать. Вот с кроликами жесть, да)

Поставьте кнопке submit по умолчанию disabled и снимайте скриптом. А чекбоксу поставьте required. Впринципе достаточно второго.

Все зависит от ваших задач.

Вариант номер раз

SELECT a.stamper,
       a.city,
       AVG(a.speed) AS AVG_SPEED,
       MAX(a.speed) AS MAX_SPEED,
       (select b.station 
        from data as b 
        where b.city=a.city and
              b.speed=max(a.speed) 
        limit 1)  as max_speed_station
FROM  data a
GROUP BY  a.stamper,
          a.city;

Вариант два
(обратите внимание, при таком типе джоина будет более одной строки после объединения если строки с подходящими скоростями в пределах города)

select a.*,
       b.station as max_speed_station
from (SELECT stamper,
             city,
             AVG(speed) AS AVG_SPEED,
             MAX(speed) AS MAX_SPEED
      FROM data
      GROUP BY stamper,
               city) as a
left join data as b
  on a.city=b.city and
     a.MAX_SPEED=b.speed;

Дело не только в ошибках и прочих нюансах. Вы можете просто нечайно или задумавшись клацнуть enter. По этой же причине рекомендуется в SQL консоли писать блок where до update/delete

NULL и пустая строка это две разные вещи, а вот у вас в запросе NULL в ковычках, это строка

Я конечно извиняюсь, но таки спрошу: а зачем? объемы несерьезные.

Смело следуйте рекомендациям как и раньше. И унесите WAL на отдельный носитель.
Ну и забудьте до появления каких либо тормозов/проблем.

Смотря что ищете. Полнотекстовый поиск это одно, поиск нечетких дубликатов второе, поиск вхождения по справочникам третье, фасеточный четвертое.

В общем случае gin индекс с pg_trgm

В Postgre нет такого механизма.

Если у вас часто возникает такая ситуация то лучше начинать с update, ибо upsert это довольно затратная штука.