[PERFORM] Slow deleting tables with foreign keys

Hi All, I'm trying to delete one row from a table and it's taking an extremely long time. This parent table is referenced by other table's foreign keys, but the particular row I'm trying to delete is not referenced any other rows in the associative tables. This table has the following structure

Re: [PERFORM] COPY with high # of clients, partitioned table locking issues?

On Wed, Mar 30, 2011 at 5:48 PM, Bob Lunney wrote: > John, > > Sorry to hear you're struggling with such underpowered hardware. ;-) A > little more information would be helpful, though: > > 1. What version of PG are you running? > 2. What are the constraints on the child tables? > 3. How man

Re: [PERFORM] COPY with high # of clients, partitioned table locking issues?

John, Sorry to hear you're struggling with such underpowered hardware. ;-) A little more information would be helpful, though: 1. What version of PG are you running? 2. What are the constraints on the child tables? 3. How many rows does each copy insert? 4. Are these wrapped in transaction

[PERFORM] COPY with high # of clients, partitioned table locking issues?

Just some information on our setup: - HP DL585 G6 - 4 x AMD Opteron 8435 (24 cores) - 256GB RAM - 2 FusionIO 640GB PCI-SSD (RAID0) - dual 10GB ethernet. - we have several tables that we store calculated values in. - these are inserted by a compute farm that calculates the results and stores the

Re: [PERFORM] very long updates very small tables

Lars Feistner wrote: > On 03/29/2011 09:28 PM, Kevin Grittner wrote: >> Lars Feistner wrote: >> >>> The log tells me that certain update statements take sometimes >>> about 3-10 minutes. But we are talking about updates on tables >>> with 1000 to 1 rows and updates that are supposed to update

Re: [PERFORM] very long updates very small tables

2011/3/30, Lars Feistner : > Hello Kevin, > > > On 03/29/2011 09:28 PM, Kevin Grittner wrote: >> Lars Feistner wrote: >> >>> The log tells me that certain update statements take sometimes >>> about 3-10 minutes. But we are talking about updates on tables >>> with 1000 to 1 rows and updates tha

Re: [PERFORM] Why Index is not used

On 03/25/2011 12:49 PM, Maciek Sakrejda wrote: Indexes aren't a magical performance fairy dust. One day I intend to use this line for the title of a presentation slide. Maybe the title of the whole talk. -- Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD PostgreSQL Trai

Re: [PERFORM] very long updates very small tables

Hello Kevin, On 03/29/2011 09:28 PM, Kevin Grittner wrote: Lars Feistner wrote: The log tells me that certain update statements take sometimes about 3-10 minutes. But we are talking about updates on tables with 1000 to 1 rows and updates that are supposed to update 1 row. The top possi