Thread

1. Insert only tables and vacuum performance

   Joseph Shraibman <jks@selectacast.net> — 2004-04-29T23:08:23Z

   I have a table that is never updated, only INSERTED into. Is there a way 
   I can prevent vacuum wasting time on this table besides vacuuming each 
   table in the db by itself and omitting this table?
   
   How feasable would it be to have a marker somewhere in pg that is 
   "updated since last vacuum" that would be cleared when vacuum runs, and 
   if set vacuum will ignore that table?
   
   

2. Re: Insert only tables and vacuum performance

   Joseph Shraibman <jks@selectacast.net> — 2004-04-29T23:24:40Z

   Joseph Shraibman wrote:
   > I have a table that is never updated, only INSERTED into. Is there a way 
   > I can prevent vacuum wasting time on this table besides vacuuming each 
   > table in the db by itself and omitting this table?
   > 
   > How feasable would it be to have a marker somewhere in pg that is 
   > "updated since last vacuum" that would be cleared when vacuum runs, and 
   > if set vacuum will ignore that table?
   
   Or even better an offset into the datatable for the earliest deleted 
   row, so if you have a table where you update the row shortly after 
   insert and then never touch it vacuum can skip most of the table 
   (inserts are done at the end of the table, right?)
   
   

3. Re: Insert only tables and vacuum performance

   Rod Taylor <pg@rbt.ca> — 2004-04-30T00:44:16Z

   > Or even better an offset into the datatable for the earliest deleted 
   > row, so if you have a table where you update the row shortly after 
   > insert and then never touch it vacuum can skip most of the table 
   > (inserts are done at the end of the table, right?)
   
   Inserts are done at the end of the table as a last resort. But anyway,
   how do you handle a rolled back insert?
   
   
   
   

4. Re: Insert only tables and vacuum performance

   Joseph Shraibman <jks@selectacast.net> — 2004-04-30T00:53:21Z

   Rod Taylor wrote:
   >>Or even better an offset into the datatable for the earliest deleted 
   >>row, so if you have a table where you update the row shortly after 
   >>insert and then never touch it vacuum can skip most of the table 
   >>(inserts are done at the end of the table, right?)
   > 
   > 
   > Inserts are done at the end of the table as a last resort.
   
   But if most of the table is never updated then the inserts would tend to 
   be at the end, right?
   
   > But anyway,
   > how do you handle a rolled back insert?
   > 
   It is considered like a deleted row to be vacuumed.
   
   

5. Re: Insert only tables and vacuum performance

   Tom Lane <tgl@sss.pgh.pa.us> — 2004-04-30T04:30:26Z

   Joseph Shraibman <jks@selectacast.net> writes:
   > I have a table that is never updated, only INSERTED into. Is there a way 
   > I can prevent vacuum wasting time on this table
   
   What makes you think vacuum is wasting much time on this table?  AFAICS
   it will only update any unfixed hint bits ...
   
   			regards, tom lane
   
   

6. Re: Insert only tables and vacuum performance

   Joseph Shraibman <jks@selectacast.net> — 2004-04-30T05:57:44Z

   Tom Lane wrote:
   > Joseph Shraibman <jks@selectacast.net> writes:
   > 
   >>I have a table that is never updated, only INSERTED into. Is there a way 
   >>I can prevent vacuum wasting time on this table
   > 
   > 
   > What makes you think vacuum is wasting much time on this table?  AFAICS
   > it will only update any unfixed hint bits ...
   > 
   > 			regards, tom lane
   
   INFO:  "elog": found 0 removable, 12869411 nonremovable row versions in 
   196195 pages
   DETAIL:  0 dead row versions cannot be removed yet.
   There were 5 unused item pointers.
   0 pages are entirely empty.
   CPU 31.61s/4.53u sec elapsed 1096.83 sec.
   
   It took 1096.83 seconds, and what did it accomplish?  And what are hint 
   bits?
   
   

7. Re: Insert only tables and vacuum performance

   Tom Lane <tgl@sss.pgh.pa.us> — 2004-05-01T03:04:36Z

   Joseph Shraibman <jks@selectacast.net> writes:
   > INFO:  "elog": found 0 removable, 12869411 nonremovable row versions in 
   > 196195 pages
   > DETAIL:  0 dead row versions cannot be removed yet.
   > There were 5 unused item pointers.
   > 0 pages are entirely empty.
   > CPU 31.61s/4.53u sec elapsed 1096.83 sec.
   
   Hmm.  These numbers suggest that your disk subsystem's bandwidth is
   only about 1.4 Mbytes/sec.  Was there a lot else going on?
   
   			regards, tom lane