Conversation

Over 5 years ago my then-colleague

wrote about problems with Postgres queues and the accumulation of garbage MVCC versions (see brandur.org/postgres-queues). Expect significant improvements in this area for Postgres 14:

postgresql.org

Re: Deleting older versions in unique indexes to avoid page splits

пн, 4 янв. 2021 г. в 17:28, Victor Yegorov : > I created another setup (see attached testcases). Basically, I …

10:23 PM · Jan 4, 2021Twitter Web App

Replying to

and

Hell yeah! This is going to be so awesome.

Replying to

and

the real question is what took you so long to make such improvements

😉

Replying to

and

Hi Soren, while implementing Oban, were you aware of this?

Replying to

and

Yes, very aware! Brandur’s articles are an amazing resource. That article in particular informed some of the design decisions in Oban:

Show replies

Replying to

and

I liked your article, thanks for sharing it! 😊 besides avoiding long transactions, do you think the use of SKIP LOCKED instead of Advisory Locks (with Recursive CTE) could improve this issue?

Replying to

and

I found almost the same question on Twitter 5 years ago (

@lukaseder

🤩):

Quote Tweet

Lukas Eder

@lukaseder

May 21, 2015

@brandur Interesting article: brandur.org/postgres-queues. Would be curious to see experiments with PG 9.5's FOR UPDATE SKIP LOCKED clause

Replying to

and

“I am going to make a … database management system … that is so … irresistible from agglomeration effects “

Replying to

and

Very useful work. To get arount this I avoid DELETEs and use partitions to periodically truncate old data from the queue. You can also avoid UPDATEs by storing a "consumer offset" on another small table a la Kafka

Replying to

and

Thanks! I'm not quite prepared to say that you should stop doing that now. More like "there are some sharp corners that will be sanded down in Postgres 14, which is good news for users in a general kind of way".