Re: autonomous transactions

From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-owner@postgresql.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