| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: refresh materialized view concurrently |
| Date: | 2013-07-03 20:04:26 |
| Message-ID: | 25398.1372881866@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Kevin Grittner <kgrittn(at)ymail(dot)com> writes:
> Further testing shows that any UPDATE or DELETE statement acquires
> a RowExclusiveLock on every index on the table and holds it until
> end of transaction, whether or not any rows are affected and
> regardless of whether an index scan or a seqscan is used. In fact,
> just an EXPLAIN of an UPDATE or DELETE does so. It is only INSERT
> which releases the locks at the end of the statement.
Hm, possibly the planner is taking those locks. I don't think the
executor's behavior is any different. But the planner only cares about
indexes in SELECT/UPDATE/DELETE, since an INSERT has no interest in
scanning the target table.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Meskes | 2013-07-03 20:48:56 | Re: [9.4 CF 1] The Commitfest Slacker List |
| Previous Message | Bruce Momjian | 2013-07-03 20:03:08 | Re: [9.4 CF 1] The Commitfest Slacker List |