Re: Small TRUNCATE glitch - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Small TRUNCATE glitch
Date
Msg-id 200805100033.m4A0Xf318007@momjian.us
Whole thread Raw
In response to Re: Small TRUNCATE glitch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Small TRUNCATE glitch
List pgsql-hackers
Added to TODO:
       o Clear table counters on TRUNCATE
         http://archives.postgresql.org/pgsql-hackers/2008-04/msg00169.php


---------------------------------------------------------------------------

Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.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
> 
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] Database owner installable modules patch
Next
From: Bruce Momjian
Date:
Subject: Re: Setting a pre-existing index as a primary key