Re: CLOG contention
Alvaro Herrera <alvherre@commandprompt.com>
From: Alvaro Herrera <alvherre@commandprompt.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Kevin Grittner <kevin.grittner@wicourts.gov>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2011-12-21T16:24:28Z
Lists: pgsql-hackers
Excerpts from Robert Haas's message of mié dic 21 13:18:36 -0300 2011: > There may be workloads where that will help, but it's definitely not > going to cover all cases. Consider my trusty > pgbench-at-scale-factor-100 test case: since the working set fits > inside shared buffers, we're only writing pages at checkpoint time. > The contention happens because we randomly select rows from the table, > and whatever row we select hasn't been examined since it was last > updated, and so it's unhinted. But we're not reading the page in: > it's already in shared buffers, and has never been written out. I > don't see any realistic way to avoid the CLOG lookups in that case: > nobody else has had any reason to touch that page in any way since the > tuple was first written. Maybe we need a background "tuple hinter" process ... -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support