← Back to context Comment by mamcx 4 days ago Is the optimization only possible using dbos? is not clear to me if this mean a way to tune normal PG 3 comments mamcx Reply KraftyOne 4 days ago The core optimization is to buffer notifications in-memory and send them in a batch instead of sending them as part of every transaction. So that's a general-purpose optimization for Postgres apps using LISTEN/NOTIFY. mamcx 4 days ago So this is not inside a trigger but on the app connected to pg? gordonhart 4 days ago Yes, per the article they “scaled” Postgres to meet their requirements by altering their usage pattern to avoid hitting the bottleneck.
KraftyOne 4 days ago The core optimization is to buffer notifications in-memory and send them in a batch instead of sending them as part of every transaction. So that's a general-purpose optimization for Postgres apps using LISTEN/NOTIFY. mamcx 4 days ago So this is not inside a trigger but on the app connected to pg? gordonhart 4 days ago Yes, per the article they “scaled” Postgres to meet their requirements by altering their usage pattern to avoid hitting the bottleneck.
mamcx 4 days ago So this is not inside a trigger but on the app connected to pg? gordonhart 4 days ago Yes, per the article they “scaled” Postgres to meet their requirements by altering their usage pattern to avoid hitting the bottleneck.
gordonhart 4 days ago Yes, per the article they “scaled” Postgres to meet their requirements by altering their usage pattern to avoid hitting the bottleneck.
The core optimization is to buffer notifications in-memory and send them in a batch instead of sending them as part of every transaction. So that's a general-purpose optimization for Postgres apps using LISTEN/NOTIFY.
So this is not inside a trigger but on the app connected to pg?
Yes, per the article they “scaled” Postgres to meet their requirements by altering their usage pattern to avoid hitting the bottleneck.