From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
---|---|
To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | AW: Plans for solving the VACUUM problem |
Date: | 2001-05-18 10:13:55 |
Message-ID: | 11C1E6749A55D411A9670001FA6879633682D2@sdexcsrv1.f000.d0188.sd.spardat.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > ???? Isn't current implementation "bulk delete" ?
>
> No, the index AM is called separately for each index tuple to be
> deleted; more to the point, the search for deletable index tuples
> should be moved inside the index AM for performance reasons.
Wouldn't a sequential scan on the heap table be the fastest way to find
keys, that need to be deleted ?
foreach tuple in heap that can be deleted do:
foreach index
call the current "index delete" with constructed key and xtid
The advantage would be, that the current API would be sufficient and
it should be faster. The problem would be to create a correct key from the heap
tuple, that you can pass to the index delete function.
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Phillips | 2001-05-18 13:07:14 | Re: Upgrade issue (again). |
Previous Message | Nathan Myers | 2001-05-18 08:19:22 | storage density |