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
