Yes, the ids is something I don't like either. They carry additional semantics, which I cannot make go away. How are chances char(20) is more time efficient than numeric(20)? Disk space is no problem here. On 12.01.2013, at 02:17, Claudio Freire <klaussfreire@xxxxxxxxx> wrote: > On Fri, Jan 11, 2013 at 8:55 PM, Horst Dehmer <horst.dehmer@xxxxxxxxx> wrote: >> Except - and that's the wall I'm hitting - for one table which yielded just >> 75 records/second. >> The main 'problem' seem to be the FK constraints. Dropping just them >> restored insert performance for this table to 6k records/s. The table in >> question has a composite PK (3 columns), 3 foreign keys and a bunch of >> indexes (see table obj_item_loc at the end of the mail). Compared to the >> other 32 tables nothing unusual. >> I'd gladly supply more information if necessary. > ... >> CREATE TABLE obj_item_loc >> ( >> obj_item_id numeric(20,0) NOT NULL, >> loc_id numeric(20,0) NOT NULL, >> obj_item_loc_ix numeric(20,0) NOT NULL, > > That sounds a lot like a missing index on the target relations (or > indices that are unusable). > > Those numeric ids look really unusual. Why not bigint? It's close to > the same precision, but native, faster, more compact, and quite > unambiguous when indices are involved. If the types don't match on > both tables, it's quite likely indices won't be used when checking the > FK, and that spells trouble. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
