SEO
vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
04-15-2008, 10:50 PM
| ||||
| ||||
 Small TRUNCATE glitch 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. 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      |
|
04-15-2008, 10:50 PM
| |||
| |||
| Re: Small TRUNCATE glitch On Thu, Apr 03, 2008 at 11:58:11AM -0400, 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. Wern't there complaints from people regularly truncating and refilling tables getting bad plans because they lost the statistics? Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH9Q2qIB7bNG8LQkwRAkfPAJ9Ps6Z78RqxtKUe86Ppvt LIeIXEZwCbB8Vi Qfl6X63uZyE6fD0l0kV3ABM= =aiBv -----END PGP SIGNATURE----- |
|
04-15-2008, 10:50 PM
| |||
| |||
| Re: Small TRUNCATE glitch Martijn van Oosterhout <kleptog@svana.org> writes: > On Thu, Apr 03, 2008 at 11:58:11AM -0400, 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. > Wern't there complaints from people regularly truncating and > refilling tables getting bad plans because they lost the statistics? Not related --- the planner doesn't look at pgstats data. 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 |
|
04-15-2008, 10:50 PM
| |||
| |||
| Re: Small TRUNCATE glitch 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. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |
|
04-15-2008, 10:50 PM
| |||
| |||
| Re: Small TRUNCATE glitch 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 |
|
05-10-2008, 02:05 PM
| ||||
| ||||
| Re: Small TRUNCATE glitch Added to TODO: o Clear table counters on TRUNCATE http://archives.postgresql.org/pgsql...4/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. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |
 |
« Auto-updated fields
|
Re: gsoc08, text search selectivity, pg_statistics holding an array of a different type »
| Thread Tools | |
| Display Modes | |
Linear Mode
|
|
All times are GMT. The time now is 01:40 AM.
