Re: ALTER TABLE lock strength reduction patch is unsafe
От | Simon Riggs |
---|---|
Тема | Re: ALTER TABLE lock strength reduction patch is unsafe |
Дата | |
Msg-id | CA+U5nMJMcwHfJ6aGrrWD+bm4+Sd3HRU9=iL5P=wta2GfR_cwKQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ALTER TABLE lock strength reduction patch is unsafe (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: ALTER TABLE lock strength reduction patch is unsafe
Re: ALTER TABLE lock strength reduction patch is unsafe |
Список | pgsql-hackers |
On Tue, Jan 3, 2012 at 3:24 PM, Robert Haas <robertmhaas@gmail.com> wrote: > I feel like the first thing we should be doing here is some > benchmarking. If we change just the scans in dependency.c and then > try the test case Tom suggested (dropping a schema containing a large > number of functions), we can compare the patched code with master and > get an idea of whether the performance is acceptable. Yes, I've done this and it takes 2.5s to drop 10,000 functions using an MVCC snapshot. That was acceptable to *me*, so I didn't try measuring using just SnapshotNow. We can do a lot of tests but at the end its a human judgement. Is 100% correct results from catalog accesses worth having when the real world speed of it is not substantially very good? (Whether its x1000000 times slower or not is not relevant if it is still fast enough). Anybody with that many DDL statements probably cares about doing various operations with lower lock levels. Fastpath locking will slow down DDL but we didn't measure the performance slow down there. We understood the benefit and were willing to pay the price. So I'll proceed for now with the patch, which isn't as simple as you think. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: