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
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
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
> 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 lock contention?
--
Sent via
Le 08/10/2015 01:40, Carlo a écrit :
>> How many cores do you have on that machine?
Test if limiting number of simultaneous feeds, like bringing their
number down to half of your normal connections has the same positive
effect.
<<
I am told 32 cores on a LINUX VM. The operators have
Sounds like a locking problem, but assuming you aren’t sherlock holmes and
simply want to get the thing working as soon as possible:
Stick a fast SSD in there (whether you stay on VM or physical). If you have
enough I/O, you may be able to solve the problem with brute force.
SSDs are a lot
rmance@postgresql.org
Subject: Re: [PERFORM] One long transaction or multiple short transactions?
Sounds like a locking problem, but assuming you aren't sherlock holmes and
simply want to get the thing working as soon as possible:
Stick a fast SSD in there (whether you stay on VM or physical). If you have
en
On Thu, Oct 08, 2015 at 11:08:55AM -0400, Carlo wrote:
> >> Sounds like a locking problem
>
> This is what I am trying to get at. The reason that I am not addressing
> hardware or OS configuration concerns is that this is not my environment,
> but my client's. The client is running my import
-Original Message-
From: k...@rice.edu [mailto:k...@rice.edu]
Sent: October 8, 2015 1:00 PM
To: Carlo
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] One long transaction or multiple short transactions?
On Thu, Oct 08, 2015 at 11:08:55AM -0400, Carlo wrote:
> >> So
On Thu, Oct 08, 2015 at 05:43:11PM -0400, Carlo wrote:
> -Original Message-
> From: k...@rice.edu [mailto:k...@rice.edu]
> Sent: October 8, 2015 1:00 PM
> To: Carlo
> Cc: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] One long transaction or multiple
transaction or multiple short transactions?
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Carlo
Sent: Monday, October 05, 2015 11:11 PM
To: pgsql-performance@postgresql.org
Subject: [PERFORM] One long transaction or mu
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Carlo
Sent: Monday, October 05, 2015 11:11 PM
To: pgsql-performance@postgresql.org
Subject: [PERFORM] One long transaction or multiple short transactions?
We have a system which
We have a system which is constantly importing flat file data feeds into
normalized tables in a DB warehouse over 10-20 connections. Each data feed
row results in a single transaction of multiple single row writes to
multiple normalized tables.
The more columns in the feed row, the more write
13 matches
Mail list logo
