Re: Partial index locks
От | Thom Brown |
---|---|
Тема | Re: Partial index locks |
Дата | |
Msg-id | CAA-aLv7tFpQPySjf2+1HpbBoH=P7+khBQ4OZy+WU1-3C6oZr+Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Partial index locks (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 22 March 2014 15:04, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thom Brown <thom@linux.com> writes: >> On 22 March 2014 05:32, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Yes. You can't determine whether the index needs to get a new entry >>> without examining its metadata, and that's what the lock is mainly about. > >> I see. Why does this apply to deletes too? > > The executor doesn't take locks on indexes for a delete. I think the > planner probably does, though, since it wants to look at all the indexes > to see if any can be used to satisfy WHERE searches. > > Possibly it would be worth hacking the planner to only take > AccessShareLock not RowExclusiveLock on target indexes in DELETE. > I can't get very excited about that though; in what circumstances > would it actually make a difference? Well I wasn't looking for things to optimise, so much as trying to understand the logic behind the existing behaviour. But thanks for the explanation. -- Thom
В списке pgsql-hackers по дате отправления: