1. 18 Apr, 1997 2 commits
  2. 28 Mar, 1997 1 commit
    • Marc G. Fournier's avatar
      From: Dan McGuirk <mcguirk@indirect.com> · 159f8c63
      Marc G. Fournier authored
      Reply-To: hackers@hub.org, Dan McGuirk <mcguirk@indirect.com>
      To: hackers@hub.org
      Subject: [HACKERS] tmin writeback optimization
      
      I was doing some profiling of the backend, and noticed that during a certain
      benchmark I was running somewhere between 30% and 75% of the backend's CPU
      time was being spent in calls to TransactionIdDidCommit() from
      HeapTupleSatisfiesNow() or HeapTupleSatisfiesItself() to determine that
      changed rows' transactions had in fact been committed even though the rows'
      tmin values had not yet been set.
      
      When a query looks at a given row, it needs to figure out whether the
      transaction that changed the row has been committed and hence it should pay
      attention to the row, or whether on the other hand the transaction is still
      in progress or has been aborted and hence the row should be ignored.  If
      a tmin value is set, it is known definitively that the row's transaction
      has been committed.  However, if tmin is not set, the transaction
      referred to in xmin must be looked up in pg_log, and this is what the
      backend was spending a lot of time doing during my benchmark.
      
      So, implementing a method suggested by Vadim, I created the following
      patch that, the first time a query finds a committed row whose tmin value
      is not set, sets it, and marks the buffer where the row is stored as
      dirty.  (It works for tmax, too.)  This doesn't result in the boost in
      real time performance I was hoping for, however it does decrease backend
      CPU usage by up to two-thirds in certain situations, so it could be
      rather beneficial in high-concurrency settings.
      159f8c63
  3. 23 Jan, 1997 1 commit
  4. 20 Jan, 1997 1 commit
    • Vadim B. Mikheev's avatar
      Fixing possible losing data changes: · 9ff69034
      Vadim B. Mikheev authored
      1. New flag - BM_JUST_DIRTIED - added for BufferDesc;
      2. All data "dirtiers" (WriteBuffer and WriteNoReleaseBuffer)
         set this flag (and BM_DIRTY too);
      3. All data "flushers" (FlushBuffer, BufferSync and BufferReplace)
         turn this flag off just before calling smgr[blind]write/smgrflush
         and check this flag after flushing buffer: if it turned ON then
         BM_DIRTY will stay ON.
      9ff69034
  5. 16 Jan, 1997 1 commit
  6. 14 Jan, 1997 1 commit
  7. 31 Dec, 1996 1 commit
  8. 08 Nov, 1996 1 commit
  9. 03 Nov, 1996 1 commit
  10. 19 Sep, 1996 1 commit
  11. 23 Jul, 1996 1 commit
  12. 09 Jul, 1996 1 commit