On 22 March 2014 15:04, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Thom Brown <t...@linux.com> writes:
>> On 22 March 2014 05:32, Tom Lane <t...@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.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to