From: | Thom Brown <thom(at)linux(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Partial index locks |
Date: | 2014-03-22 15:13:26 |
Message-ID: | CAA-aLv7tFpQPySjf2+1HpbBoH=P7+khBQ4OZy+WU1-3C6oZr+Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 22 March 2014 15:04, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thom Brown <thom(at)linux(dot)com> writes:
>> On 22 March 2014 05:32, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-03-22 15:13:56 | Re: Inheritance of foregn key constraints. |
Previous Message | Tom Lane | 2014-03-22 15:04:02 | Re: Partial index locks |