Re: slow cursor
От | Benjamin Krajmalnik |
---|---|
Тема | Re: slow cursor |
Дата | |
Msg-id | 8511B4970E0D124898E973DF496F9B4357E0F6@stash.stackdump.local обсуждение исходный текст |
Ответ на | Re: slow cursor ("Sriram Dandapani" <sdandapani@counterpane.com>) |
Список | pgsql-admin |
From: pgsql-admin-owner@postgresql.org on behalf of Sriram Dandapani
Sent: Thu 4/20/2006 9:45 PM
To: Jim C. Nasby
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] slow cursor
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:jnasby@pervasive.com]
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 jnasby@pervasive.com
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
В списке pgsql-admin по дате отправления:
Предыдущее
От: Alvaro HerreraДата:
Сообщение: Re: Howto: Using PITR recovery for standby replication
Следующее
От: "Benjamin Krajmalnik"Дата:
Сообщение: Re: Howto: Using PITR recovery for standby replication