Thread: discussion on proposed int8_ops patch

Hello hackers...

Enclosed below I have a patch to allow a btree index on the int8 type.  

I would like some feedback on what the hash function for the int8 hash function 
in the ./backend/access/hash/hashfunc.c should return.

Also, could someone (maybe Tomas Lockhart?) look-over the patch and make sure 
the system table entries are correct?  I've tried to research them as much as I 
could, but some of them are still not clear to me.

Thanks,
-Ryan

P.S. I claimed the following OID's for this implimentation:754 and 842 (for the btree index)949 for the hash index (not
totallyimplimented yet.)
 

I got these by using the ./include/catalog/unused_oids script.  I hope they were 
not being resererved for something els4.


*** ./backend/access/hash/hashfunc.c.orig    Mon Feb 22 15:30:41 1999
--- ./backend/access/hash/hashfunc.c    Mon Feb 22 15:31:32 1999
***************
*** 32,37 ****
--- 32,49 ----     return ~key; } 
+ /*
+  * I'm not sure how to impliment this hash function
+  * -Ryan (2/22/1999)
+  */
+ #ifdef NOT_USED
+ uint32
+ hashint8(uint64 *key)
+ {
+     return ~((uint32)key);
+ }
+ #endif /* NOT_USED */
+  /* Hash function from Chris Torek. */ uint32 hashfloat4(float32 keyp)
*** ./backend/access/nbtree/nbtcompare.c.orig    Mon Feb 22 14:14:56 1999
--- ./backend/access/nbtree/nbtcompare.c    Mon Feb 22 15:02:41 1999
***************
*** 40,45 ****
--- 40,56 ---- }  int32
+ btint8cmp(int64 *a, int64 *b)
+ {
+     if (*a > *b)
+         return 1;
+     else if (*a == *b)
+         return 0;
+     else
+         return -1;
+ }
+ 
+ int32 btint24cmp(int16 a, int32 b) {     return ((int32) a) - b;
*** ./include/catalog/pg_amop.h.orig    Mon Feb 22 14:14:37 1999
--- ./include/catalog/pg_amop.h    Mon Feb 22 15:42:14 1999
***************
*** 168,173 ****
--- 168,183 ---- DATA(insert OID = 0 (  403 426 521 5 btreesel btreenpage ));  /*
+  *    nbtree int8_ops
+  */
+ 
+ DATA(insert OID = 0 (  403 754 412 1 btreesel btreenpage ));
+ DATA(insert OID = 0 (  403 754 414 2 btreesel btreenpage ));
+ DATA(insert OID = 0 (  403 754 410 3 btreesel btreenpage ));
+ DATA(insert OID = 0 (  403 754 415 4 btreesel btreenpage ));
+ DATA(insert OID = 0 (  403 754 413 5 btreesel btreenpage ));
+ 
+ /*  *    nbtree oid_ops  */ 
***************
*** 338,343 ****
--- 348,364 ---- DATA(insert OID = 0 (  405    423  670 1 hashsel hashnpage )); /* int4_ops */ DATA(insert OID = 0 (
405   426   96 1 hashsel hashnpage ));
 
+ 
+ /*
+  * Add this when I figure out the int8 hash function.
+  * -Ryan (2/22/1999)
+  */
+ 
+ #ifdef NOT_USED
+ /* int8_ops */
+ /* DATA(insert OID = 0 (  405    426   96 1 hashsel hashnpage )); */
+ #endif
+  /* oid_ops */ DATA(insert OID = 0 (  405    427  607 1 hashsel hashnpage )); /* oid8_ops */
*** ./include/catalog/pg_amproc.h.orig    Mon Feb 22 14:14:27 1999
--- ./include/catalog/pg_amproc.h    Mon Feb 22 14:57:54 1999
***************
*** 92,97 ****
--- 92,98 ---- DATA(insert OID = 0 (403  435  404 1)); DATA(insert OID = 0 (403  436  948 1)); DATA(insert OID = 0 (403
437  828 1));
 
+ DATA(insert OID = 0 (403  754  842 1)); DATA(insert OID = 0 (403 1076 1078 1)); DATA(insert OID = 0 (403 1077 1079
1));DATA(insert OID = 0 (403 1114 1092 1));
 
*** ./include/catalog/pg_opclass.h.orig    Mon Feb 22 14:13:53 1999
--- ./include/catalog/pg_opclass.h    Mon Feb 22 14:26:33 1999
***************
*** 93,98 ****
--- 93,100 ---- DESCR(""); DATA(insert OID =  714 (    circle_ops        718   )); DESCR("");
+ DATA(insert OID =  754 (    int8_ops         20   ));
+ DESCR(""); DATA(insert OID = 1076 (    bpchar_ops       1042   )); DESCR(""); DATA(insert OID = 1077 (    varchar_ops
  1043   ));
 
No differences encountered
*** ./include/catalog/pg_proc.h.orig    Mon Feb 22 14:14:16 1999
--- ./include/catalog/pg_proc.h    Mon Feb 22 15:41:57 1999
***************
*** 735,740 ****
--- 735,742 ---- DESCR("btree less-equal-greater"); DATA(insert OID = 351 (  btint4cmp           PGUID 11 f t f 2 f 23
"2323" 
 
100 0 0 100  foo bar )); DESCR("btree less-equal-greater");
+ DATA(insert OID = 842 (  btint8cmp           PGUID 11 f t f 2 f 23 "20 20" 
100 0 0 100  foo bar ));
+ DESCR("btree less-equal-greater"); DATA(insert OID = 352 (  btint42cmp           PGUID 11 f t f 2 f 23 "23 21" 
100 0 0 100  foo bar )); DESCR("btree less-equal-greater"); DATA(insert OID = 353 (  btint24cmp           PGUID 11 f t
f2 f 23 "21 23" 
 
100 0 0 100  foo bar ));
***************
*** 821,826 ****
--- 823,838 ---- DESCR("hash"); DATA(insert OID = 450 (  hashint4           PGUID 11 f t f 2 f 23 "23 23" 
100 0 0 100  foo bar )); DESCR("hash");
+ 
+ /*
+  * Add this when I figure out the int8 hash function.
+  * -Ryan (2/22/1999)
+  */
+ #ifdef NOT_USED
+ /* DATA(insert OID = 949 (  hashint8           PGUID 11 f t f 2 f 23 "20 20" 
100 0 0 100  foo bar )); */
+ /* DESCR("hash"); */
+ #endif /* NOT_USED */
+  DATA(insert OID = 451 (  hashfloat4           PGUID 11 f t f 2 f 23 "700 
700" 100 0 0 100    foo bar )); DESCR("hash"); DATA(insert OID = 452 (  hashfloat8           PGUID 11 f t f 2 f 23 "701

701" 100 0 0 100    foo bar ));
No differences encountered
*** ./include/utils/builtins.h.orig    Mon Feb 22 15:05:19 1999
--- ./include/utils/builtins.h    Mon Feb 22 15:06:17 1999
***************
*** 163,168 ****
--- 163,169 ----  */ extern int32 btint2cmp(int16 a, int16 b); extern int32 btint4cmp(int32 a, int32 b);
+ extern int32 btint8cmp(int64 *a, int64 *b); extern int32 btint24cmp(int16 a, int32 b); extern int32 btint42cmp(int32
a,int16 b); extern int32 btfloat4cmp(float32 a, float32 b);
 

> Enclosed below I have a patch to allow a btree index on the int8 type.
> I would like some feedback on what the hash function for the int8 hash 
> function in the ./backend/access/hash/hashfunc.c should return.
> Also, could someone (maybe Tomas Lockhart?) look-over the patch and 
> make sure the system table entries are correct?

I've got the patches and have applied them (with a bit of fix-up) to my
current source tree. I would like to look at them in more detail before
committing them to the source tree, but I'm sure you've gotten most of
the important stuff.

istm that the int8 hash function can look just like the int4 hash
function, coercing the int8 input down to int4 first. afaik this isn't a
problem, in that int8->int4 overflows are not signaled. I've enabled
this hash strategy in your code.

> P.S. I claimed the following OID's for this implimentation:
>         754 and 842 (for the btree index)
>         949 for the hash index (not totally implimented yet.)
> I got these by using the ./include/catalog/unused_oids script.

Those should be fine, and that was the right way to choose them.

Sorry that I'm out of town until next week, but I should be able to
finish things then. Thanks for the patches.
                   - Tom

Applied, though there was some wrapping of the e-mail I had to clean up.

Your hash code looks fine, so I enabled it by removing the ifdef's.  You
could XOR the top int4 bytes with the bottom int4 bytes, but I doubt
there is a portable way to do that, so you are better off just leaving
it as is, where it looks at only the lower int32 bytes.

If you copied how the other entries pointed to other entries, your code
will be fine.

> Hello hackers...
> 
> Enclosed below I have a patch to allow a btree index on the int8 type.  
> 
> I would like some feedback on what the hash function for the int8 hash function 
> in the ./backend/access/hash/hashfunc.c should return.
> 
> Also, could someone (maybe Tomas Lockhart?) look-over the patch and make sure 
> the system table entries are correct?  I've tried to research them as much as I 
> could, but some of them are still not clear to me.
> 

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

> Applied, though there was some wrapping of the e-mail I had to clean 
> up.
> Your hash code looks fine, so I enabled it by removing the ifdef's.  
> > Enclosed below I have a patch to allow a btree index on the int8 
> > type.
> > I would like some feedback on what the hash function for the int8 
> > hash function in the ./backend/access/hash/hashfunc.c should return.
> > Also, could someone (maybe Tomas Lockhart?) look-over the patch and 
> > make sure the system table entries are correct?  I've tried to 
> > research them as much as I could, but some of them are still not 
> > clear to me.

*argh* I had responded to Ryan and the list that there were problems
with the patch and that I would fix it up and then apply to the tree.
So don't expect this stuff to work as-is, and now I'll have to figure
out what else has changed :(

Man, I go away for two weeks and look at what happens ;)
                           - Tom

> > Applied, though there was some wrapping of the e-mail I had to clean 
> > up.
> > Your hash code looks fine, so I enabled it by removing the ifdef's.  
> > > Enclosed below I have a patch to allow a btree index on the int8 
> > > type.
> > > I would like some feedback on what the hash function for the int8 
> > > hash function in the ./backend/access/hash/hashfunc.c should return.
> > > Also, could someone (maybe Tomas Lockhart?) look-over the patch and 
> > > make sure the system table entries are correct?  I've tried to 
> > > research them as much as I could, but some of them are still not 
> > > clear to me.
> 
> *argh* I had responded to Ryan and the list that there were problems
> with the patch and that I would fix it up and then apply to the tree.
> So don't expect this stuff to work as-is, and now I'll have to figure
> out what else has changed :(

Sorry.  I don't remember seeing your comments.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026