Re: Drop in performance for each INSERT/DELETE combo
От | Dalibor Andzakovic |
---|---|
Тема | Re: Drop in performance for each INSERT/DELETE combo |
Дата | |
Msg-id | CC7B0539958DBD429731F8B41BEAA6EE079EBA@wassup.swerve.co.nz обсуждение исходный текст |
Ответ на | Drop in performance for each INSERT/DELETE combo (Turbo Fredriksson <turbo@bayour.com>) |
Список | pgsql-hackers |
Did you try this using temporary tables? I've noticed a better performance on one of our apps that used to do just that (insert some records and delete some records from a sctrach table) We recoded it to basically create a temp table, insert records, do whatever with them and than drop the temp table. This is easily achieved with CREATE TEMP TABLE Hope this helps dali -----Original Message----- From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Turbo Fredriksson Sent: Wednesday, 6 March 2002 21:20 To: pgsql-hackers@postgresql.org Subject: [HACKERS] Drop in performance for each INSERT/DELETE combo We're using a function to insert some information into the database. This information is later (within seconds) retrieved from a program, that does the actual processing of the information. It is then deleted from the database when we're done with it. We see a MAJOR performance loss the longer the time. It starts out from around 28 'data chunks' per second (inserts in a couple tables), and drops down to below 10/s... If doing 'VACUUM ANALYZE' every 20 minutes improves the performance, with the expected drop when the VACUUM is done, but in general the performance is steady... Investigation have shown that it's the actual DELETE that's slow, any idea how to find WHERE (and hopefully WHY :) this is so? -- attack Serbian radar PLO ammonium toluene Legion of Doom congress DES pits Ft. Bragg KGB Honduras kibo World Trade Center [See http://www.aclu.org/echelonwatch/index.html for more about this] ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
В списке pgsql-hackers по дате отправления: