From: [email protected]
[mailto:[email protected]] 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
