| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Thom Brown <thom(at)linux(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Partial index locks |
| Date: | 2014-03-22 15:04:02 |
| Message-ID: | 18480.1395500642@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thom Brown | 2014-03-22 15:13:26 | Re: Partial index locks |
| Previous Message | Tom Lane | 2014-03-22 15:00:47 | Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors |