Re: [PERFORM] One long transaction or multiple short transactions?

2015-10-17 Thread Jim Nasby
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

Re: [PERFORM] One long transaction or multiple short transactions?

2015-10-17 Thread Andres Freund
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 e

Re: [PERFORM] One long transaction or multiple short transactions?

2015-10-17 Thread Jim Nasby
On 10/9/15 3:33 AM, Graeme B. Bell wrote: I don't think inserts can cause contention on the server. Insert do not lock tables during the transaction. You may have contention on sequence but it won't vary with transaction size. Perhaps there could be a trigger on inserts which creates some l

Re: [PERFORM] SELECT slows down on sixth execution

2015-10-17 Thread Pavel Stehule
2015-10-17 15:29 GMT+02:00 Yves Dorfsman : > On 2015-10-14 03:00, Albe Laurenz wrote: > > > > You are encountering "custom plans", introduced in 9.2. > > > > When a statement with parameters is executed, PostgreSQL will not only > generate > > a generic plan, but for the first 5 executions it will

Re: [PERFORM] SELECT slows down on sixth execution

2015-10-17 Thread Yves Dorfsman
On 2015-10-14 03:00, Albe Laurenz wrote: > > You are encountering "custom plans", introduced in 9.2. > > When a statement with parameters is executed, PostgreSQL will not only > generate > a generic plan, but for the first 5 executions it will substitute the > arguments > and generate and execu