| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: Small TRUNCATE glitch |
| Date: | 2008-04-03 22:23:39 |
| Message-ID: | 25100.1207261419@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> Just noticed that TRUNCATE fails to clear the stats collector's counts
>> for the table. I am not sure if it should reset the event counts or
>> not (any thoughts?) but surely it is wrong to not zero the live/dead
>> tuple counts.
> Agreed, the live/dead counters should be reset. Regarding event counts,
> my take is that we should have a separate statement count for truncate
> (obviously not a tuple count), and the others should be left alone.
I thought some more about how to do it, and stumbled over how to cope
with TRUNCATE being rolled back. That nixed my first idea of just
having TRUNCATE send a zero-the-counters-now message.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2008-04-03 22:48:19 | Re: psql \G command -- send query and output using extended format |
| Previous Message | Tom Lane | 2008-04-03 22:21:57 | Re: psql \G command -- send query and output using extended format |