1 соединение на N сеансов или N соединений на N cеансов

очевидно же, нужно держать готовый пул соединений. Открытые нового соединения относительно дорогая операция для СУБД и особенно для PG.

Разница в том, что на открытие соединения тратится некоторое время вот и все. Поэтому вариант б, чуток лучше, но учитывая кол-во запросов к бд на соединение, разницей можно пренебречь.

Одно-единственное соединение выдержит только определенную нагрузку. Нужно сделать несколько соединений к БД одновременно, и держать их сколько сможешь (а при падении переоткрывать), и распределять между ними нагрузку. Гугл Database Connection Pool

Открытие нового конекшена может занимать несколько секунд, а одна транзакция - доли секунды. Т.е. если нет возможности/желания городить пул, лучше сделать одно долгоживущее соединение.

Да. Но нужно иметь в виду что у персистентных конектов есть подводные камни. Это не фатальный недостаток, но всё-же лучше помнить об этом работая с ними.

Про возможные грабли рассказано например там:
http://profyclub.ru/docs/145

сли нет возможности/желания городить пул

apt-get install pgpool2

Открытие нового конекшена может занимать несколько секунд

Ну это загнул конечно. Если у тебя столько времени коннект занимает, значит сеть лежит.

на каком-то из облачных хостингов, кажись Хероку, на халявном аккаунте бд - постгрес на амазоне. Можно было поспать пока после конекшена транзакция начнет выполняться. Может и из-за сети, но у меня было ощущение что тормозит сам сервер из-за нагрузки (не дай бох зайти туда через pgadmin3 и кликнуть куда-нибудь не туда, сразу досвидос). Наверное, если у ТСа планируются сотни тысяч пользователей одновременно, поведение будет таким же.

Про возможные грабли рассказано например там:

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

Дык, каждый день новые интересные открытия, не соскучишься.