zlacker

[parent] [thread] 2 comments
1. lmm+(OP)[view] [source] 2023-09-25 03:28:49
> This is similar to saying, 'if I mess up all the tables in one database I wreck the rest'. Just my opinion, but this is not actually a thing in databases.

If you mess up the tables in one database it doesn't affect others, but if you lock up the server where it can't respond to queries, that affects every database running on that server.

> Also, if you run one postgres, you won't have of an issue running another if you have the experience in production.

We're talking about using a different feature that you presumably haven't used before, so you won't necessarily know about the admin side of that.

replies(1): >>j16sdi+a7
2. j16sdi+a7[view] [source] 2023-09-25 05:09:22
>>lmm+(OP)
> If you mess up the tables in one database it doesn't affect others, but if you lock up the server where it can't respond to queries, that affects every database running on that server.

How is it different from: putting multiple queues on same redis, when one queue is locked up, others queue are affected?

If that's a real risk, you can always put them into different instances. The solution is exactly the same for redis or postgresql

replies(1): >>lmm+cb3
◧◩
3. lmm+cb3[view] [source] [discussion] 2023-09-25 22:31:38
>>j16sdi+a7
> How is it different from: putting multiple queues on same redis, when one queue is locked up, others queue are affected?

Queues by nature tend to be for tasks that you can tolerate delaying a bit. If your queues can impact your "live"/online processing, that's worse than just impacting other queues.

Also something like redis tends to be a lot simpler and less prone to locking up than the monster that is postgresql.

[go to top]