Re: autonomous transactions

From: pgsql-hackers-owner(at)postgresql(dot)org [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Craig Ringer
> Of course, if we could decrease the startup cost of a bgworker

For this use in autonomous tx's we could probably pool workers. Or at least lazily terminate them so that the loop cases work better by re-using an existing bgworker.

Though I may say something odd, isn’t the bgworker approach going to increase context switches? I thought PostgreSQL has made efforts to decrease context switches, e.g.

* Each backend itself writes WAL to disk unlike Oracle requests LGWR process to write REDO to disk.

* Releasing and re-acquiring a lwlock appears to try to avoid context switches.

/*

* Loop here to try to acquire lock after each time we are signaled by

* LWLockRelease.

*

* NOTE: it might seem better to have LWLockRelease actually grant us the

* lock, rather than retrying and possibly having to go back to sleep. But

* in practice that is no good because it means a process swap for every

* lock acquisition when two or more processes are contending for the same

* lock. Since LWLocks are normally used to protect not-very-long

* sections of computation, a process needs to be able to acquire and

* release the same lock many times during a single CPU time slice, even

* in the presence of contention. The efficiency of being able to do that

* outweighs the inefficiency of sometimes wasting a process dispatch

* cycle because the lock is not free when a released waiter finally gets

* to run. See pgsql-hackers archives for 29-Dec-01.

*/

I’m not sure whether to be nervous about the context switch cost in the use cases of autonomous transactions.

Regards

Takayuki Tsunakawa