:
On 22.11.2010 23:18, Peter Tanski wrote:
Whatever test I use for Same(), Penalty() and Consistent() does not seem
to affect the problem significantly. For now I am only using
Consistent() as a check for retrieval.
I believe it's not possible to lose leaf tuples with incorrectly defined
I should correct what I just wrote: the first and last entries in
entryvec-vector are invalid.
On Nov 23, 2010, at 11:39 AM, Peter Tanski wrote:
Picksplit() seems to be an exceptional case here: the first and last
numbers in entryvec are invalid so
entryvec-vector[entryvec-n - 1
Picksplit() seems to be an exceptional case here: the first and last
numbers in entryvec are invalid so
entryvec-vector[entryvec-n - 1]
is invalid. All the other GiST code Picksplit() functions use the
same convention. For example, see the btree_gist picksplit function, at
On Nov 23, 2010, at 1:37 PM, Yeb Havinga wrote:
j = 0;
for (i = FirstOffsetNumber; i maxoff; i = OffsetNumberNext(i)) {
FPrint* v = deserialize_fprint(entv[i].key);
Isn't this off by one? Offset numbers are 1-based, so the maxoff
computation is wrong.
The first for loop of all others
of where the keys are over
2000 bytes in size. So GiST definitely handles large keys. Perhaps the
maximum size for intarray could be increased.
On Nov 23, 2010, at 4:01 PM, Yeb Havinga wrote:
On 2010-11-23 20:54, Peter Tanski wrote:
On Nov 23, 2010, at 1:37 PM, Yeb Havinga wrote:
j = 0
I have been working on a plugin for GiST that has some unusual features:
* The data type for both Node and Leaf keys is large (typically 4222
bytes on 32-bit; 4230 bytes on 64-bit).
* Due to the large size the storage class is EXTENDED (main would only
degrade to EXTENDED in any case).
= f2.fingerprint)
(The previous query example used the ~= operator which was defined to
match at .5 but in this case there no matches in the table so ~= is
the same as =.)
On Nov 22, 2010, at 4:18 PM, Peter Tanski wrote:
I have been working on a plugin for GiST that has some unusual
