postgres best practice - queuing table for many consumers

What is the best practice to implement the following in postgres:

• One system puts tasks into a queue, about 5.000 per minute. The tasks carry a payload of varying sizes (a few KB to several MB)
• Several consumers now pick up these tasks. First, they mark a task as taken (in-progress). Then, when the task is done they remove the task from the queue.

The way we are doing it is having a table 'tasks' that has a column 'status' and a column 'payload'. Into this table 5000 tasks are inserted per minute. These 5000 records are then - each individually, as each task is processed individually - updated to status=in-progress. Then, these 5000 records are deleted - again individually - when the tasks are done. We have several indexes on the table, the payload sits in the table (albeit sometimes toasted). We are seeing a very high amount of WALWrite because of this, which makes sense. We do not see disabling synchronous commit as an option.

So I am curious how would such a queuing system optimally look in postgres? Use several tables instead of one? Insert only tables? No indexes (for HOT-updates)? Payload in separate table that is not updated and maybe deleted asynchronously?

You have tasks and you have a queue - these look like two tables to me. Your task has its id and payload data etc. Your queue has the task id, timestamps, status etc.

If you want some sort of "automagical" synchronisation of this stuff, you can have triggers to queue any new tasks and an ON DELETE foreign key that removes the queue item when the task is deleted.