Tom Lane wrote:
> Bruce Momjian <br...@momjian.us> writes:
> > + This means that UPDATE, DELETE, and SELECT can trigger space
> > + reclamation, while INSERT ... VALUES cannot because it does not retrieve
> > + a row.
> 
> I don't believe that's correct.  It might have happened to work that way
> for you in a particular test.  It's certainly not something I'd document
> as being intended long-term behavior.

Well, I would like to document something about this because I was
surprised that when INSERT did not trigger a cleanup.  I realize we
might change the behavior but then we would update the file too,
hopefully.

How is the attached version using "often"?  I also clarified it is < 10%
free.

I found this while doing tests for a new MVCC talk I will be delivering
at PG West.

-- 
  Bruce Momjian  <br...@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +
Index: src/backend/access/heap/README.HOT
===================================================================
RCS file: /cvsroot/pgsql/src/backend/access/heap/README.HOT,v
retrieving revision 1.6
diff -c -c -r1.6 README.HOT
*** src/backend/access/heap/README.HOT  23 Apr 2010 23:21:44 -0000      1.6
--- src/backend/access/heap/README.HOT  17 Sep 2010 21:21:56 -0000
***************
*** 246,251 ****
--- 246,257 ----
  is arbitrarily capped at MaxHeapTuplesPerPage (the most tuples that
  could fit without HOT pruning).
  
+ Effectively, space reclamation happens during tuple retrieval when the
+ page is nearly full (<10% free) and a buffer cleanup lock can be
+ acquired.  This means that UPDATE, DELETE, and SELECT can trigger space
+ reclamation, but often not during INSERT ... VALUES because it does
+ not retrieve a row.
+ 
  
  VACUUM
  ------
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to