Ok, so why does that require row-by-row processing? On Thu, Apr 20, 2006 at 08:45:57PM -0700, Sriram Dandapani wrote: > Yes..all of it is in one transaction as there is a window of record ids > that need to be processed in 1 transaction. Data inflow is very > voluminous appx 1 million every 15 minutes and the goal is to create > aggregate tables on the fly (the alternative is to use nightly > aggregates). > > -----Original Message----- > From: Jim C. Nasby [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 20, 2006 7:36 PM > To: Sriram Dandapani > Cc: pgsql-admin@postgresql.org > Subject: Re: [ADMIN] slow cursor > > On Mon, Apr 17, 2006 at 07:07:54AM -0700, Sriram Dandapani wrote: > > I have a cursor that fetches 150K rows and updates or inserts a table > > with 150K rows. > > > > It takes several minutes for the process to complete (about 15 > minutes). > > The select by itself (without cursor) gets all rows in 15 seconds. > > > > Is there a way to optimize the cursor to fetch all records and speed > up > > the process. I still need to do the record by record processing > > Not likely. Are you at least doing all this inside a transaction? > -- > Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] > Pervasive Software http://pervasive.com work: 512-231-6117 > vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org >
-- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
