| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Index vacuum improvements |
| Date: | 2006-03-31 16:50:17 |
| Message-ID: | 9780.1143823817@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> On Wed, 29 Mar 2006, Tom Lane wrote:
>> That loses the ability to reflect tuple deadness back into LP_DELETE
>> flags, no?
> At first glance, it doesn't look so hard. index_getmulti could mark
> those tids that are dead, and btgetmulti would rescan the index page and
> set LP_DELETE on all tuples that are still there.
> We don't have to care about splits; if the index tuple is no longer where
> it used to be, just ignore it. Right, no?
True --- as long as there's even a reasonable probability of the tuple
getting marked, we'll get the performance benefit. I don't see a way to
make it work for bitmap indexscans though --- by the time we visit the
heap, the index has long since forgotten where those index entries were.
I think this may be worth doing even disregarding any possible vacuum
speedup, simply because it'll reduce the number of index page lock/unlock
cycles needed during a regular indexscan.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jonah H. Harris | 2006-03-31 17:09:34 | Re: pg_class catalog question... |
| Previous Message | Simon Riggs | 2006-03-31 16:46:39 | Re: WAL dirty-buffer management bug |