Re: CLOG contention
От | Alvaro Herrera |
---|---|
Тема | Re: CLOG contention |
Дата | |
Msg-id | 1324484624-sup-2565@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: CLOG contention (Robert Haas <robertmhaas@gmail.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: