Re: ALTER TABLE lock strength reduction patch is unsafe
От | Simon Riggs |
---|---|
Тема | Re: ALTER TABLE lock strength reduction patch is unsafe |
Дата | |
Msg-id | CA+U5nM+_h-6w9DwKQDym3684hSvy34yfAhRa5z3vtT+JYyrdDw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ALTER TABLE lock strength reduction patch is unsafe (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: ALTER TABLE lock strength reduction patch is unsafe
|
Список | pgsql-hackers |
On Mon, Jan 2, 2012 at 5:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: >> Assuming that is the right approach, some timings > > Um ... timings of what? Apologies for being terse, no problem to give a full explanation. You suggested earlier that putting calls to GetSnapshotData() in place of using SnapshotNow might increase the time taken to do catalog scans. That matters most in places where stuff isn't cached, one such place you suggested might be the dependency check code, so a test of dropping thousands of functions might show up any bad regressions. From what I can see, there are no bad performance regressions from making SnapshotNow use MVCC. We're benefiting in 9.2 from good reductions in GetSnapshotData() contention and improved performance anyway, so it looks like a reasonable balance. I'm proposing that we apply the above patch (v4) to allow SnapshotNow scans to return consistent, trustable results. That fixes some of the corner case bugs we've seen and paves the way for me to re-enable the lock reduction code. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: