←back to thread

Postgres LISTEN/NOTIFY does not scale

(www.recall.ai)
570 points davidgu | 5 comments | 07 Jul 25 14:05 UTC | HN request time: 0.02s | source
Show context
polote ◴[10 Jul 25 20:38 UTC] No.44525307[source]▶
Rls and triggers dont scale either
replies(2): >>44525677 #>>44525805 #
shivasaxena ◴[10 Jul 25 21:12 UTC] No.44525677[source]▶
Yeah, I'm going to remove triggers in next deploy of a POS system since they are adding 10-50ms to each insert.

Becomes a problem if you are inserting 40 items to order_items table.

replies(5): >>44525741 #>>44526565 #>>44526644 #>>44526757 #>>44526964 #
1. candiddevmike ◴[10 Jul 25 22:58 UTC] No.44526644[source]▶
How do you handle trigger logic that compares old/new without having a round trip back to the application?
replies(1): >>44527025 #
2. SoftTalker ◴[10 Jul 25 23:58 UTC] No.44527025[source]▶
Do it in a stored procedure not a trigger. Triggers have their place but a stored procedure is almost always better. Triggers can surprise you.
replies(1): >>44527147 #
3. candiddevmike ◴[11 Jul 25 00:17 UTC] No.44527147[source]▶
I don't follow how you would do that in a stored procedure outside of a trigger.
replies(1): >>44527554 #
4. const_cast ◴[11 Jul 25 01:27 UTC] No.44527554{3}[source]▶
I think instead of performing an INSERT you call a stored proc that does the insert and some extra stuff.
replies(1): >>44535087 #
5. shivasaxena ◴[11 Jul 25 17:48 UTC] No.44535087{4}[source]▶
Yes, we already have all of our business logic in postgres functions(create_order, create_partial_payment etc).

Doing the extra work in stored procedures is noticeably faster than relying on triggers.