aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/heap/heapam.c
Commit message (Collapse)AuthorAge
...
* Another PGINDENT run that changes variable indenting and case label ↵Bruce Momjian1997-09-08
| | | | indenting. Also static variable indenting.
* Massive commit to run PGINDENT on all *.c and *.h files.Bruce Momjian1997-09-07
|
* heap_delete returns int now (for non-functional deletes).Vadim B. Mikheev1997-08-27
|
* Make functions static where possible, enclose unused functions in #ifdef ↵Bruce Momjian1997-08-19
| | | | NOT_USED.
* Remove more (void) and fix -Wall warnings.Bruce Momjian1997-08-12
|
* Catch non-functional delete attempts.Vadim B. Mikheev1997-08-06
|
* From: Dan McGuirk <mcguirk@indirect.com>Marc G. Fournier1997-03-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Removed unlinked patch that is not neede now that Vadim has properly fixed it.Bruce Momjian1997-01-23
|
* Fix for SELECT INTO ... GROUP/ORDER BY where table already exists unlink error.Bruce Momjian1997-01-01
|
* More cleanupsMarc G. Fournier1996-11-05
|
* Changes required so that access/* compiles cleanly...Marc G. Fournier1996-11-03
| | | | cleaning up behind myself before *yawn* bed :)
* Cleaned out -I../.. -I../../include from MakefileMarc G. Fournier1996-10-31
| | | | Added missing include files
* -Wall'dMarc G. Fournier1996-10-21
|
* First pass at fixing my own mistakesMarc G. Fournier1996-10-20
| | | | | | Mainly...fix up the includes I removed, as well as prototypes Pointed out by D'Arcy
* Another directory cleaned outMarc G. Fournier1996-10-20
|
* The patch does several things:Marc G. Fournier1996-08-24
| | | | | | | | | | | | | | | | | | | It adds a WITH OIDS option to the copy command, which allows dumping and loading of oids. If a copy command tried to load in an oid that is greater than its current system max oid, the system max oid is incremented. No checking is done to see if other backends are running and have cached oids. pg_dump as its first step when using the -o (oid) option, will copy in a dummy row to set the system max oid value so as rows are loaded in, they are certain to be lower than the system oid. pg_dump now creates indexes at the end to speed loading Submitted by: Bruce Momjian <maillist@candle.pha.pa.us>
* Postgres95 1.01 Distribution - Virgin SourcesPG95-1_01Marc G. Fournier1996-07-09