At 20:42 4/07/00 +0200, Jan Wieck wrote:
>
> So an index (built out of the values in the
> main tuple after toasting) will also contain the plain
> values. Thus, index scans will not require toast fetches in
> turn. Except the indexed attribute had at some point a huge
> value.
So that, for toasted attrs, the indexes will be no use for sorting. I agree
that in the majority of cases this is not a problem, but if the entire
tuple gets toasted because it is too large it becomes a problem.
I agree that this is only a problem if indexes are used in sorting, and may
not be a problem if one builds an index on 'substr(toastable-field,1,20)',
but I think you are suggesting not supporting functional indexes,
below...but maybe I've missed the point.
> The current TOAST implementation hooks into the heap access
> methods only. Automagically covering the index issues due to
> the 2K approach. Fact is, that if more toast entries can get
> produced during index inserts, we need to take care for them
> during vacuum (the only place where index items get removed).
> Alot of work just to support huge functional indices - IMHO
> not worth the efford right now. Let's better get some
> experience with the entire thing before going too far.
>
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \| | --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
