> We might have part of the story in the recently noticed fact that
> each insert/update query begins by doing a seqscan of pg_index.
> 
> I have done profiles of INSERT in the past and not found any really
> spectacular bottlenecks (but I was looking at a test table with no
> indexes, so I failed to see the pg_index problem :-().  Last time
> I did it, I had these top profile entries for inserting 100,000 rows
> of 30 columns apiece:

Well, I've dropped index but INSERTs still take 70 sec and 
COPY just 1sec -:(((

Vadim

Fri, 26 May 2000 11:32:20 -0700
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Berkeley DB... 
> -----Original Message-----
> From: pgsql-hackers-owner@hub.org 
> [mailto:pgsql-hackers-owner@hub.org]On Behalf Of Mikheev, Vadim
> 
> > We might have part of the story in the recently noticed fact that
> > each insert/update query begins by doing a seqscan of pg_index.
> > 
> > I have done profiles of INSERT in the past and not found any really
> > spectacular bottlenecks (but I was looking at a test table with no
> > indexes, so I failed to see the pg_index problem :-().  Last time
> > I did it, I had these top profile entries for inserting 100,000 rows
> > of 30 columns apiece:
> 
> Well, I've dropped index but INSERTs still take 70 sec and 
> COPY just 1sec -:(((
>

Did you run vacuum after dropping indexes ?
Because DROP INDEX doesn't update relhasindex of pg_class,
planner/executer may still look up pg_index.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp 

Sat, 27 May 2000 12:11:58 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: Berkeley DB... 