| From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
|---|---|
| To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | AW: AW: Plans for solving the VACUUM problem |
| Date: | 2001-05-18 13:58:52 |
| Message-ID: | 11C1E6749A55D411A9670001FA6879633682D5@sdexcsrv1.f000.d0188.sd.spardat.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> A particular point worth making is that in the common case where you've
> updated the same row N times (without changing its index key), the above
> approach has O(N^2) runtime. The indexscan will find all N index tuples
> matching the key ... only one of which is the one you are looking for on
> this iteration of the outer loop.
It was my understanding, that the heap xtid is part of the key now, and thus
with a somewhat modified access, it would find the one exact row directly.
And in above case, the keys (since identical except xtid) will stick close
together, thus caching will be good.
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2001-05-18 14:35:36 | Re: AW: AW: Plans for solving the VACUUM problem |
| Previous Message | Tom Lane | 2001-05-18 13:47:55 | Re: AW: Plans for solving the VACUUM problem |