Re: REVIEW: Track TRUNCATE via pgstat

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
Date: 2015-01-23 20:58:57
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
truncate-and-pgstat-v0.5.patch text/x-diff 20.4 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
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