|From:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>|
|To:||Alex Shulgin <ash(at)commandprompt(dot)com>|
|Cc:||Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: REVIEW: Track TRUNCATE via pgstat|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
|Next Message||Andrew Gierth||2015-01-23 21:13:03||Abbreviated keys for Datum tuplesort (was: Re: B-Tree support function number 3 (strxfrm() optimization))|
|Previous Message||Bruce Momjian||2015-01-23 20:52:46||Re: pg_upgrade and rsync|