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
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
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
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
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
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
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:
