Re: REVIEW: Track TRUNCATE via pgstat - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: REVIEW: Track TRUNCATE via pgstat
Date
Msg-id 20150123205857.GQ1663@alvh.no-ip.org
Whole thread Raw
In response to Re: REVIEW: Track TRUNCATE via pgstat  (Alex Shulgin <ash@commandprompt.com>)
Responses Re: REVIEW: Track TRUNCATE via pgstat
Re: REVIEW: Track TRUNCATE via pgstat
List 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

Attachment

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade and rsync
Next
From: Andrew Gierth
Date:
Subject: Abbreviated keys for Datum tuplesort (was: Re: B-Tree support function number 3 (strxfrm() optimization))