Re: [PERFORM] Insert performance for large transaction with multiple COPY FROM

2013-01-18 Thread Horst Dehmer
Hey Jeff (and others)! First of all: Thanks for your detailed explanations and guide lines. On 17.01.2013, at 18:12, Jeff Janes wrote: > So the theory is that the presence of idx_4 is causing the trigger to > pick a poor plan (i.e. one using idx_4) while its absence removes that > temptation?

Re: [PERFORM] Insert performance for large transaction with multiple COPY FROM

2013-01-15 Thread Horst Dehmer
stuff I'm asking here, but especially point 2 is bothering me. -- Kind regards Horst Dehmer On 12.01.2013, at 01:17, Jeff Janes wrote: > On Friday, January 11, 2013, Horst Dehmer wrote: > > Except - and that's the wall I'm hitting - for one table which yielded just &g

Re: [PERFORM] Insert performance for large transaction with multiple COPY FROM

2013-01-12 Thread Horst Dehmer
(20,0) NOT NULL, ... CONSTRAINT obj_item_pkey PRIMARY KEY (obj_item_id), … ) CREATE UNLOGGED TABLE rptd ( rptd_id numeric(20,0) NOT NULL, ... CONSTRAINT rptd_pkey PRIMARY KEY (rptd_id), … ) On 12.01.2013, at 23:18, Claudio Freire wrote: > On Sat, Jan 12, 2013 at 5:16 PM, Horst Dehme

Re: [PERFORM] Insert performance for large transaction with multiple COPY FROM

2013-01-12 Thread Horst Dehmer
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 wrote: > On Fri, Jan 11, 2013 at 8:55 P

[PERFORM] Insert performance for large transaction with multiple COPY FROM

2013-01-11 Thread Horst Dehmer
nderstand is, which limit it is I'm hitting here. I need some advice how to 'profile' this situation. Configuration is more or less standard, except WAL settings (which should not be relevant here). EnterpriseDB One Click installer. Any hint is really appreciated. Thanks! --