ztxn

>>Стоит ли в этом случае делает индекс составным и кластеризованным?
Составной индекс по паре (time, account), для отбора по экаунту наверняка вам будет бесполезен. А для отбора по экаунту и диапазону времени (или с сортировкой по времени и отсечкой по top/значению времени), он будет существенно менее эффективен нежели по паре (account, time)

Наверняка отбор по экаунту производится с сортировкой по time и отсечкой по time либо же top, либо же по диапазону time. В этом случае, мне думается, будет уместен составной индекс по паре (account,time)

Вот кластеризованный — ли, берут меня сомнения. Нужны дли вам на столько дополнительные пять копеек при отборе, чтобы можно было чуть пожертвовать производитеьностью на вставке? Полагаю — врядли. Скорость вставки, мне думается, тут весьма критична будет.

Пг — версионник, у него запись не блокирует чтение, MS — блокировочник. Изоляция транзакций реализована совершенно по разному.

Простой пример:
ms, выполняя запрос insert into table (value) select max(value) +1 from table, в read commited не допустит дублирования значений при вставке несколькими сессиями, а в PG — запросто.

В этом контексте на MySQL может оказаться переехать куда проще. Он тоже блокировочник.