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 totally implimented 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 "23 23"
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 f 2 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, Pennsylvania 19026Applied, 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, Pennsylvania 19026