From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Re: vacuum timings |
Date: | 2000-01-25 09:53:57 |
Message-ID: | 388D72B5.88F36E5F@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian wrote:
> > > Quite a few people have reported finding the opposite in practice.
> > > You should probably try vacuuming after deleting or updating some
> > > fraction of the rows, rather than just the all or none cases.
> > >
> >
> > Vacuum after delelting all rows isn't a worst case.
> > There's no moving in that case and vacuum doesn't need to call
> > index_insert() corresponding to the moving of heap tuples.
> >
> > Vacuum after deleting half of rows may be one of the worst case.
> > In this case,index_delete() is called as many times as 'delete all'
> > case and expensive index_insert() is called for moved_in tuples.
>
> I will test that.
>
I tried my test case in less scale than Bruce.
CREATE TABLE t (id int4, dt int4);
for (i=0; i < 2500000; i++)
insert into t values ( i, (i * 1009) % 2500000);
delete from t where id < 1250000;
1) vacuum after create index on t(id) 405sec
2) vacuum after create index on t(dt) > 3600sec
I gave up to continue execution.
3) vacuum and create index on t(id) and t(dt)
90sec + 114sec + 143sec = 347sec.
Seems random index insert is painful for vacuum.
Regards.
Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2000-01-25 10:30:30 | Re: [SQL] Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace |
Previous Message | Alfred Perlstein | 2000-01-25 08:42:00 | Re: [HACKERS] Oh btw, about XXX |