| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Gregory Stark <gsstark(at)mit(dot)edu> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-patches(at)postgresql(dot)org, teramoto(dot)junji(at)lab(dot)ntt(dot)co(dot)jp |
| Subject: | Re: [HACKERS] Resurrecting per-page cleaner for btree |
| Date: | 2006-07-26 15:29:51 |
| Message-ID: | 2220.1153927791@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
Gregory Stark <gsstark(at)mit(dot)edu> writes:
> ... Well it's not like the existing vacuum checks for this.
Right, that's exactly why the patch works at all. But the point here is
that the existing vacuum does not rely on re-computing index keys; all
it cares about is matching TIDs. The retail-vacuum idea depends on the
assumption that you can look at the tuple and re-compute the same index
keys that you computed the first time; which is an assumption much
shakier than the assumption that TID comparison works. (In fact, it's
trivial to see how user-defined functions that are mislabeled immutable
could make this fail.) So retail vacuum without any cross-check that
you got all the index tuples is a scary proposition IMHO.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | andrew | 2006-07-26 15:29:57 | Re: pgbench enhancements |
| Previous Message | Martijn van Oosterhout | 2006-07-26 15:29:27 | Re: Refactoring the API for amgetmulti |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Albe Laurenz | 2006-07-26 15:33:52 | Re: LDAP lookup of connection parameters |
| Previous Message | Tom Lane | 2006-07-26 15:16:29 | Re: patch implementing the multi-argument aggregates (SOC project) |