{"push_id":811392495,"size":1,"distinct_size":1,"ref":"refs/heads/REL9_5_STABLE","head":"8c8a834b14712de5252858aebbd4c5900c105c78","before":"91d97f03ca2a9ed56b322b69dde0392db835f722","commits":[{"sha":"8c8a834b14712de5252858aebbd4c5900c105c78","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"message":"Improve LISTEN startup time when there are many unread notifications.\n\nIf some existing listener is far behind, incoming new listener sessions\nwould start from that session's read pointer and then need to advance over\nmany already-committed notification messages, which they have no interest\nin.  This was expensive in itself and also thrashed the pg_notify SLRU\nbuffers a lot more than necessary.  We can improve matters considerably\nin typical scenarios, without much added cost, by starting from the\nfurthest-ahead read pointer, not the furthest-behind one.  We do have to\nconsider only sessions in our own database when doing this, which requires\nan extra field in the data structure, but that's a pretty small cost.\n\nBack-patch to 9.0 where the current LISTEN/NOTIFY logic was introduced.\n\nMatt Newell, slightly adjusted by me","distinct":true,"url":"https://api.github.com/repos/postgres/postgres/commits/8c8a834b14712de5252858aebbd4c5900c105c78"}]}