(www.recall.ai)

570 points davidgu | 3 comments | 07 Jul 25 14:05 UTC | HN request time: 0s | source

Show context

polote ◴[10 Jul 25 20:38 UTC] No.44525307[source]▶

Rls and triggers dont scale either

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.

How do you handle trigger logic that compares old/new without having a round trip back to the application?

replies(1): >>44527025 #

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 #

1. 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 #

2. const_cast ◴[11 Jul 25 01:27 UTC] No.44527554[source]▶

I think instead of performing an INSERT you call a stored proc that does the insert and some extra stuff.

replies(1): >>44535087 #

3. shivasaxena ◴[11 Jul 25 17:48 UTC] No.44535087[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.

Postgres LISTEN/NOTIFY does not scale