Re: [PERFORM] Terrible Write Performance of a Stored Procedure

2009-06-30 Thread valgog
On Jun 26, 9:30 pm, goofyheadedp...@gmail.com (Brian Troutwine) wrote: > Hello, all. > >  CREATE OR REPLACE FUNCTION item_data_insert( >         iasin TEXT, iauthor TEXT, ibinding TEXT, icurrency_code TEXT, >         iisbn TEXT, iheight INTEGER, iwidth INTEGER, ilength INTEGER, > iweight INTEGER, >

Re: [PERFORM] Terrible Write Performance of a Stored Procedure

2009-06-29 Thread Scott Mead
> > You're right that it should be removed, but this explanation is wrong. The > behavior as configured is actually "if there are >=100 other transactions in > progress, wait 0.1 second before committing after the first one gets > committed", in hopes that one of the other 100 might also join along

Re: [PERFORM] Terrible Write Performance of a Stored Procedure

2009-06-26 Thread Greg Smith
On Fri, 26 Jun 2009, Scott Mead wrote:     Having those settings enabled basically does the following:    " Do not complete the I/O for a commit until you have either commit_siblings commits also ready, or you have waited .55 seconds."   Basically, if you make 1 commit, you will sit there wait

Re: [PERFORM] Terrible Write Performance of a Stored Procedure

2009-06-26 Thread Scott Mead
On Fri, Jun 26, 2009 at 4:36 PM, Brian Troutwine wrote: > > Turn commit delay and commit siblings off. > > Why? Sorry about the short and sweet, was driving: Having those settings enabled basically does the following: " Do not complete the I/O for a commit until you have either commit

Re: [PERFORM] Terrible Write Performance of a Stored Procedure

2009-06-26 Thread Brian Troutwine
> Turn commit delay and commit siblings off. Why? Brian On Fri, Jun 26, 2009 at 1:06 PM, Scott Mead wrote: > -- sorry for the top-post and short response. > > Turn commit delay and commit siblings off. > > --Scott > > On 6/26/09, Brian Troutwine wrote: >> Hello, all. >> >> I'm finding that writ

Re: [PERFORM] Terrible Write Performance of a Stored Procedure

2009-06-26 Thread Brian Troutwine
> Indexes are good things. Try them. Particularly on the isbn field. I'm not sure why amazon_items.isbn should be given an index. item_details.isbn is used in a WHERE clause and is given an index accordingly, but not amazon_items.isbn. Brian On Fri, Jun 26, 2009 at 12:40 PM, Alan Hodgson wrote

Re: [PERFORM] Terrible Write Performance of a Stored Procedure

2009-06-26 Thread Merlin Moncure
On Fri, Jun 26, 2009 at 3:30 PM, Brian Troutwine wrote: > Hello, all. > > I'm finding that write performance of a certain stored procedure is > abysmal. I need to be able to sustain approximately 20 calls to this > procedure per second, but am finding that, on the average, each call > takes 2 secon

Re: [PERFORM] Terrible Write Performance of a Stored Procedure

2009-06-26 Thread Alan Hodgson
On Friday 26 June 2009, Brian Troutwine wrote: > CREATE TABLE amazon_items ( > asin char(10) PRIMARY KEY, > locale varchar(10) NOT NULL DEFAULT 'US', > currency_code char(3) DEFAULT 'USD', > isbn char(13), > sales_rank integer, >