Re: REVIEW: Track TRUNCATE via pgstat
От | Alvaro Herrera |
---|---|
Тема | Re: REVIEW: Track TRUNCATE via pgstat |
Дата | |
Msg-id | 20150123205857.GQ1663@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: REVIEW: Track TRUNCATE via pgstat (Alex Shulgin <ash@commandprompt.com>) |
Ответы |
Re: REVIEW: Track TRUNCATE via pgstat
Re: REVIEW: Track TRUNCATE via pgstat |
Список | pgsql-hackers |
Here's v0.5. (Why did you use that weird decimal versioning scheme? You could just say "v4" and save a couple of keystrokes). This patch makes perfect sense to me now. I was ready to commit, but I checked the regression test you added and noticed that you're only reading results for the last set of operations because they all use the same table and so each new set clobbers the values for the previous one. So I modified them to use one table for each set, and report the counters for all tables. In doing this I noticed that the one for trunc_stats_test3 is at odds with what your comment in the .sql file says; would you review it please? Thanks. (I didn't update the expected file.) BTW you forgot to update expected/prepared_xact_1.out, for the case when prep xacts are disabled. If some other committer decides to give this a go, please remember to bump catversion before pushing. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: