RE: Berkeley DB...

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Hannu Krosing" <hannu(at)tm(dot)ee>
Cc: "Mike Mascari" <mascarm(at)mascari(dot)com>, "Matthias Urlichs" <smurf(at)noris(dot)de>, <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: Berkeley DB...
Date: 2000-05-27 03:11:58
Message-ID: NDBBIJLOILGIKBGDINDFMEHPCFAA.Inoue@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: pgsql-hackers-owner(at)hub(dot)org
> [mailto:pgsql-hackers-owner(at)hub(dot)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(at)tpf(dot)co(dot)jp

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-05-27 04:06:54 Re: Re: [SQL] aliases break my query
Previous Message Thomas Lockhart 2000-05-27 02:36:01 Back online