AlexBoss

В настоящее время (pg15) уникальное ограничение может быть только btree индексом.
Следовательно, общее для btree правило префиксного поиска. btree(a,b,c) может так же эффективно использоваться для поиска по префиксу - where a = ? или where a = ? and b = ? - но не может эффективно использоваться для where b = ? или where c = ?

Например для Postgres on_conflict_do_nothing
Или INSERT…ON CONFLICT
У меня Postgres, я сделал on_conflict_do_update так:

class HeroCard(db.Model):
    id = db.Column(db.Integer, primary_key=True, nullable=False)
    heroid = db.Column(db.Integer, ForeignKey('hero.id'))
    cardid = db.Column(db.Integer, ForeignKey('card.id'))
    count = db.Column(db.Integer)
    db.UniqueConstraint(heroid, cardid, name='hero_card_un')

upd = insert(HeroCard).values(heroid=id, cardid=cid, count=count)
do_upd_upd = upd.on_conflict_do_update(constraint='hero_card_un', set_={'count': HeroCard.count+count})
db.session.execute(do_upd_upd)
db.session.commit()

Конечно, у докера есть оверхэд. В реальности ты его не заметишь.

Проектировать приложение нужно так, чтобы оно могло масштабироваться горизонтально. Не стоит думать, что разница между приложением, запущенным прямо на VPS и приложением, запущенным в докере на этом же VPS — это "вот как раз то, чего не хватало". Если CPU/Networking упирается в 100%, то это повод разворачивать ещё несколько идентичных серверов и размазывать нагрузку. А это в сто раз легче сделать, если у тебя контейнеры.

Более детальный анализ: https://stackoverflow.com/questions/21889053/what-...

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

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

Не питонист, но попробую ответить. Сам GIL живет внутри процесса, поэтому создание нескольких копий одного процесса вполне возможно. GIL разных процессов никак не будут пересекаться. Разные процессы могут обрабатывать разные данные. У разных процессов нет общей памяти ( если мы не учитываем shared-memory ). Разные процессы могут делать много полезного - парсить файлы, обрабатывать пользовательские запросы и тд.

С потоками все иначе. Так все потоки принадлежат одному процессу, и у них общая память GIL уже обойти нельзя. Но есть нюанс. Если поток выполняет некую системную функцию, в общем не связанную с самим питоном то таких функций можно выполнять одновременно любое количество. Основные примеры таких функций - чтение запись данных в файлы ( или в сокеты ). То есть можно принимать сразу множество сообщений в разных потоках, но как только мы вывалимся в питон код GIL снова вступит в силу и начнет их выполнять по очереди.

Не надо это делать в шаблоне, даже если очень хочется.

Но если вы очень упрямый, можете написать кастомный template tag.

def c1(value):
    return value.upper()

def c2(value):
    return ord(value)

functions = [c1, c2]
values = ['a', 'b', 'c']

with multiprocessing.Pool() as p:
    results = p.map(lambda f: f(), [lambda f=f, v=v: f(v) for v in values for f in functions])
    print(results)

CRON) info (No MTA installed, discarding output)

поставьте вы MTA какой нить, в мыло прийдет лог работы скрипта

Ну или просто перенаправьте вывод скрипта в файл