563 Commits (ff89e182d42048380dba32fee1b491893c7b4bec)

Author	SHA1	Message	Date
Vadim B. Mikheev	d6b8f637f9	CommitInfoNeedsSave[buffer - 1] = 0 ... added to WriteBuffer(), FlushBuffer(), WriteNoReleaseBuffer().	29 years ago
Vadim B. Mikheev	d3dfc664d0	PrintBufferUsage() changed to report about shared, local and direct ... blocks transfferes.	29 years ago
Marc G. Fournier	159f8c63ad	From: Dan McGuirk <mcguirk@indirect.com> ... 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.	29 years ago
Marc G. Fournier	37a8bdba43	The second patch adds a more explicative error message to BufferPoolCheckLeak. ... It should be completely harmless. Submitted by: Massimo Dal Zotto <dz@cs.unitn.it>	29 years ago
Vadim B. Mikheev	9ff69034b2	Fixing possible losing data changes: ... 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.	29 years ago
Vadim B. Mikheev	eb08b3ce4f	No more LateWrite, but there is WriteMode; ... SetBufferWriteMode () added; FlushBuffer () fixed: now directly calls smgrflush () and releases buffer only if required by caller.	29 years ago
Vadim B. Mikheev	2ca05fe45d	ReleaseTmpRelBuffers is ReleaseRelationBuffers now.	29 years ago
Vadim B. Mikheev	ae753b86b5	ReleaseTmpRelBuffers () releases buffers in LOCAL buffer pool now ... (if rd_islocal is true).	29 years ago
Bruce Momjian	4b2b8592a0	Compile and warning cleanup	29 years ago
Marc G. Fournier	66637f4a2f	Clean up Makefile ... Add #include "postgres.h" as required Remove #include "utils/elog.h"	29 years ago
Marc G. Fournier	aceac3a927	Fix for pg_log bug ... Submitted by: "Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>	29 years ago
Marc G. Fournier	b619cb09d9	iBrought in a fix for backend crashes ... Submitted by: "Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>	30 years ago
Marc G. Fournier	d31084e9d1	Postgres95 1.01 Distribution - Virgin Sources	30 years ago