| From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | "Graeme B(dot) Bell" <graeme(dot)bell(at)nibio(dot)no>, Laurent Martelli <laurent(dot)martelli(at)enercoop(dot)org>, "pgsql-performance(at)postgresql(dot)org list" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: One long transaction or multiple short transactions? |
| Date: | 2015-10-17 20:43:29 |
| Message-ID: | 5622B2F1.2000406@BlueTreble.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 10/17/15 12:13 PM, Andres Freund wrote:
> On 2015-10-17 10:26:01 -0500, Jim Nasby wrote:
>> Except inserts *do* take a lot of locks, just not user-level locks.
>> Operations like finding a page to insert into, seeing if that page is in
>> shared buffers, loading the page into shared buffers, modifying a shared
>> buffer, getting the relation extension lock if you need to add a new page.
>> Then there's a whole pile of additional locking you could be looking at for
>> inserting into any indexes.
>>
>> Now, most of the locks I described up there are transaction-aware
>
> Missing *not*?
Oops. Yes, they're *not* transaction-aware.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2015-10-19 16:47:30 | Re: SELECT slows down on sixth execution |
| Previous Message | Andres Freund | 2015-10-17 17:13:38 | Re: One long transaction or multiple short transactions? |