Re: RFC: Logging plan of the running query
От | Fujii Masao |
---|---|
Тема | Re: RFC: Logging plan of the running query |
Дата | |
Msg-id | a398dab8-486c-4a54-5aa6-f9faab2ea1fa@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: RFC: Logging plan of the running query (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: RFC: Logging plan of the running query
|
Список | pgsql-hackers |
On 2022/02/01 17:27, Kyotaro Horiguchi wrote: >> * Similar to relation extension, page locks are also held for a short >> * duration, so imposing such a restriction won't hurt. > > I don't believe a path involving vacuum_delay_point() calls is > short-duration'ed. Yes. >> One thing that really bothers me about commit e2c79e14 is that >> LockPage() is called, not LockBuffer(). GIN had no LockPage() calls >> before that commit, and is now the only code in the entire system that >> calls LockPage()/ConditionalLockPage() (the hash am no longer uses >> page heavyweight locks following recent work there). > > I agree to the discussion. Can't we use other mechanism here to get > rid of the Lockpage()? I have no good idea for that yet, but I agree it's better to get rid of page level lock. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: