Re: [GENERAL] So slow inserts... Why?
От | Michal Samek |
---|---|
Тема | Re: [GENERAL] So slow inserts... Why? |
Дата | |
Msg-id | 374CEA17.9B2E2378@tony.cz обсуждение исходный текст |
Список | pgsql-general |
First of all many thanks to all people trying to help me. Now I'm testing my job with the postgresql in various conditions, with applying interesting suggestions from you, and I'm getting crazy a bit :) I must say that it's not so clear to leave the dBase world and start the SQL Master :) What about writting some doc of optimizing postgresql more explaining the behaviour of the backend? (Maybe I've missed some part of docs but I don't think so.) Now I know that my problem is more SELECT's cost when lookuping than INSERT's cost. I want to say what I can see that it helped me the best: About TWO-THREE times QUICKER is my job after : 1. Dropping all indexes (included theese like table_record_key and table_pkey (if you have the primary key) ) - I must say that I was a bit surprised that it's possible to drop these "system-level" indexes. How it would affect on primary uniq key when I drop it's index? Will it still be uniq, or not? 2. VACUUMing the table - it's really short and I think this should be documented, that it's much better than VACUUM performed on indexed table. Before you explained me it I thought that VACUUM on indexed table should take the time of VACUUM on non-indexed table plus the time of indexes creating :) 3. Recreating all the indexes included these two which you created together with table (I'm not sure if it's right): create unique index table_pkey on table(primary_key_name) ; create unique index table_record_key on table(oid) ; And for me it's a bit surprising, that something like "index quallity" is decreasing with INSERT's. Isn't it ? -- Michal Samek, Tony distribuce s.r.o. webmaster@tony.cz (++420659/321350) ICQ: 38607210
В списке pgsql-general по дате отправления: