Earlier quoted context omitted.
"Toy/low throughput" = "Toy or low throughout"
Can you define "low throughput"? I think people have significantly different ideas of what that means.
Choose Postgres queue technology
321–330 of 369 posts
Re: Choose Postgres queue technology
#322Re: Choose Postgres queue technology
#323For several projects I’ve opted for the even dumber approach, that works out of the box with every ORM/Query DSL framework in every language: using a normal table with SELECT FOR UPDATE SKIP LOCKED https://www.pgcasts.com/episodes/the-skip-locked-feature-in-... It’s not “web scale” but it easily extends to several thousand background jobs in my experience
Re: Choose Postgres queue technology
#324Earlier quoted context omitted.
> If I want to use NOTIFY in postgres? I googled "SQLALchemy notify listen postgres" and I find a few unanswered stackoverflow questions and a github gist that has some code but no context. Author here. I would say that my post is less targeted at someone like you (application developer, presumably) and more targeted at library developers. I don't think it's ideal for everyone to be implementing bespoke, Postgres-bac…
Thank you for writing this. I love the article's point, and I tend to feel that the "chasing the cargo cult of 'scale'" is maybe the biggest problem I see in development teams today. It is certainly the biggest problem that I rarely hear anybody talking about. Author here. I would say that my post is less targeted at someone like you (application developer, presumably) and more targeted at library developers. I think…
Re: Choose Postgres queue technology
#325Earlier quoted context omitted.
"Toy/low throughput" = "Toy or low throughout"
Can you define "low throughput"? I think people have significantly different ideas of what that means.
IDK maybe Not saying SKIP LOCKED can't work with that many. But you'll probably want to do something with lower overhead.
FWIW, Que uses advisory locks [1]
Re: Choose Postgres queue technology
#326Earlier quoted context omitted.
Queue can clearly mean "work that needs to be completed" not necessarily 'work completed in order'. Your definition is much stricter than it needs to be for most use cases.
not necessarily 'work completed in order' That's exactly what a queue means, not just in every day life, but specifically in computer science.
Re: Choose Postgres queue technology
#327Earlier quoted context omitted.
not necessarily 'work completed in order' That's exactly what a queue means, not just in every day life, but specifically in computer science.
This depends if we consider a priority queue to be a type of queue.
Re: Choose Postgres queue technology
#328Earlier quoted context omitted.
> If I want to use NOTIFY in postgres? The nice thing about "boring" tech like Postgres is that it has great documentation. So just peruse https://www.postgresql.org/docs/current/sql-notify.html . No need for google-fu.
Python, Flask, SQLAlchemy, and Postgres all have great documentation individually, but if I am building an application at the intersection often a guide on exactly how to join them all up is much faster than using each individually and trying to figure out the interactions in four places. AWS white papers and engineering blogs tend to give me everything I need in one place, and I don't think there are any for apps bu…
Re: Choose Postgres queue technology
#329Earlier quoted context omitted.
Disimbue is also a word with an appropriate meaning-- even if it's archaic (and no longer appears in most dictionaries) and pretentious.
No, I won't believe it until I see evidence. Did you find it in a credible source? Which one(s)? I've found nothing credible in Merriam Webster, Etymology Online, nor _any_ other I've searched. There is at least one low-quality ad-serving site that credits ChatGPT with a definition. I'm happy to be enlightened.
Re: Choose Postgres queue technology
#330If you're on a cloud provider, I'd say just use their offering. For small/medium amounts of messages (single digit millions a day) the cost will be trivial. A lot of frameworks already have queue/job libraries with adapters (so you're not really locked in) and cloud providers are highly scalable and fault tolerant. It seems silly to try to build into Postgres something that is already cheap and readily available unle…
> If you're on a cloud provider, I'd say just use their offering. For small/medium amounts of messages (single digit millions a day) the cost will be trivial. It's a good compromise but not suitable for every use case. The thing I really don't like is that you need to be connected to the cloud even for local development and test.
If you're architecture is on AWS, you're most likely using either one of those solutions.