From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
Cc: | PostgreSQL HACKERS <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: TOAST & vacuum |
Date: | 2000-07-21 18:29:50 |
Message-ID: | 23354.964204190@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
JanWieck(at)t-online(dot)de (Jan Wieck) writes:
> TOAST is now vacuum-safe. When needed, the toaster creates a
> second heap tuple, containing only plain or compressed
> values. This one is then returned by the heap access methods
> to the caller, so indices will never contain external
> references.
That should be sufficient for insertions into existing indexes,
but what about CREATE INDEX on a column that already contains
toasted values? That works with fetched tuples, not ones formed
during insert/update.
I think a cleaner and more reliable short-term hack would be to twiddle
index_formtuple() to detoast any externally-stored attributes. AFAIK,
in current sources all paths for creating an index tuple go through that
routine, and it has a tupdesc handy so it knows which attributes are of
varlena type.
This way you wouldn't need to hack up the tuptoaster itself.
Also, this would work for functional indexes whereas the way you are
doing it will not (a function could return a toasted Datum extracted
from some other table, no?).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2000-07-21 18:29:53 | Re: About these IPC parameters |
Previous Message | Oliver Elphick | 2000-07-21 15:51:20 | Re: Shared library search paths |