Re: Reducing relation locking overhead
От | Kevin Brown |
---|---|
Тема | Re: Reducing relation locking overhead |
Дата | |
Msg-id | 20051203170952.GC6827@filer обсуждение исходный текст |
Ответ на | Re: Reducing relation locking overhead (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Reducing relation locking overhead
|
Список | pgsql-hackers |
Tom Lane wrote: > Kevin Brown <kevin@sysexperts.com> writes: > > In the above for large relations, the bulk of the REINDEX should > > happen without any locks being held by the REINDEX operation. > > As I just pointed out to Greg, the arm-waving notion that you can "turn > off the FSM" requires a great deal of low-level locking that is not > there now. Yeah, I thought that the check for use of the FSM was already being done by the lower level operators, and that contention would only occur on the modification of the FSM "enabled" flag. Obviously this doesn't work at all if the FSM is just assumed to be in use at all times, or if the FSM values are read only at transaction start or something... > Even ignoring that, you *still* have a lock upgrade problem > in this sketch. Hmm, well, I can see a deadlock potential for those operations that have to acquire multiple locks simultaneously, and I suppose that the table + FSM lock would qualify in the sequence here, but the rest of it involves just a single read lock against the table. What am I missing? -- Kevin Brown kevin@sysexperts.com
В списке pgsql-hackers по дате отправления: