Teodor Sigaev <[EMAIL PROTECTED]> writes:
> ... Which ways I see:
> 5 There is one unused bit in IndexTupleData. GiST code can use it as
> mark that this tuple contains incorrect union key. In this case, GiST
> search algorithm should keep it mind that such tuple has incorrect
> value and always should go to it's child to check. During insertions
> in tree such tuples will be little by little changed to
> correct. Defect of this scheme will be a possible performance
> degradation after crash recovery. In other hand, it's possible to add
> recreation such tuples to vacuum code (in gistbulkdelete).
This seems like a good answer --- if you fix up such things during
vacuum then the performance issue won't last too long.
Rather than eating up the extra flag bit, though, would it be possible
to change the tuple to appear to contain a NULL? AFAIK, GiST can't have
a NULL (at least not in the first column) so this should be an unused
state.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
