On Thu, Dec 3, 2015 at 1:48 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > I think the way to address is don't add backend to Group list if it is > not intended to update the same page as Group leader. For transactions > to be on different pages, they have to be 32768 transactionid's far apart > and I don't see much possibility of that happening for concurrent > transactions that are going to be grouped.
That might work. >> My idea for how this could possibly work is that you could have a list >> of waiting backends for each SLRU buffer page. > > Won't this mean that first we need to ensure that page exists in one of > the buffers and once we have page in SLRU buffer, we can form the > list and ensure that before eviction, the list must be processed? > If my understanding is right, then for this to work we need to probably > acquire CLogControlLock in Shared mode in addition to acquiring it > in Exclusive mode for updating the status on page and performing > pending updates for other backends. Hmm, that wouldn't be good. You're right: this is a problem with my idea. We can try what you suggested above and see how that works. We could also have two or more slots for groups - if a backend doesn't get the lock, it joins the existing group for the same page, or else creates a new group if any slot is unused. I think it might be advantageous to have at least two groups because otherwise things might slow down when some transactions are rolling over to a new page while others are still in flight for the previous page. Perhaps we should try it both ways and benchmark. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
