From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | 'Craig Ringer' <craig(dot)ringer(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Subject: | Re: autonomous transactions |
Date: | 2016-09-08 00:18:06 |
Message-ID: | 0A3221C70F24FB45833433255569204D1F5E7867@G01JPEXMBYT05 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2016-09-08 00:36:47 | Re: Is tuplesort_heap_siftup() a misnomer? |
Previous Message | Michael Paquier | 2016-09-08 00:05:45 | Re: Long options for pg_ctl waiting |