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:
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 fo
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
http://doxyge
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
t here -- we handle the memory
PG_RETURN_POINTER(entry);
}
I'll put together a test case and send that on.
On Nov 23, 2010, at 2:29 AM, Heikki Linnakangas wrote:
> On 22.11.2010 23:18, Peter Tanski wrote:
>> Whatever test I use for Same(), Penalty() and Consistent() does not see
ngerprint = 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
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). Tes