Is there anyway to create a TupleDesc with uint32 attribute easily?

Hi, hackers.
I'm working on my gsoc project - improving hash index.
I need to create a TupldeDesc with uint32 attribute.
Here is the reason why I need it -
If we store hash code only in the tuple, then the TupleDesc's
attribute should be uint32.
In this way, we can use index_form_tuple() to create a tuple and
needn't write a function for hash specially.

I've tried lookup_rowtype_tupdesc() with INT4OID, but it dosen't work
since int is not composite type.
Is there any easy way to do it or I should change my design?
Hope to hear from you. Thanks!

--
Best Regards,
Xiao Meng

DKERC, Harbin Institute of Technology, China
Gtalk: mx(dot)cogito(at)gmail(dot)com
MSN: cnEnder(at)live(dot)com
http://xiaomeng.yo2.cn

Xiao Meng wrote:
> Hi, hackers.
> I'm working on my gsoc project - improving hash index.
> I need to create a TupldeDesc with uint32 attribute.
> Here is the reason why I need it -
> If we store hash code only in the tuple, then the TupleDesc's
> attribute should be uint32

Something along the lines of:

TupleDesc tupdesc = CreateTemplateTupleDesc(1, false);
TupleDescInitEntry(tupdesc, 1, "hashcode", INT4OID, -1, 0);

> In this way, we can use index_form_tuple() to create a tuple and
> needn't write a function for hash specially.

I would actually suggest ditching the normal page layout with line
pointers and IndexTuples altogether. All the entries are fixed size, so
you can get away with a much simpler structure, and store more entries
per page. Storing an IndexTuple with one int32 column takes

(sizeof(IndexTupleData) + sizeof(uint32) + sizeof(ItemIdData)) = 16 bytes,

but you only need a pointer to the heap tuple, and the hash code, which
is just 10 bytes in total. Or 12 if you have to align the hash code to 4
byte boundary.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Oh, I almost forget the problem of item size.
What I consider is just to modify the source code as few as possible;-(
Thank you for reminding me, Heikki.
I can see in the older version of postgresql, it remove a structure
HashItem and just use indextuple to store the item.
Now I would use a structure HashItem to store it again;-)

On Tue, Jul 15, 2008 at 8:04 PM, Heikki Linnakangas
<heikki(at)enterprisedb(dot)com> wrote:
> Xiao Meng wrote:
>>
>> Hi, hackers.
>> I'm working on my gsoc project - improving hash index.
>> I need to create a TupldeDesc with uint32 attribute.
>> Here is the reason why I need it -
>> If we store hash code only in the tuple, then the TupleDesc's
>> attribute should be uint32
>
> Something along the lines of:
>
> TupleDesc tupdesc = CreateTemplateTupleDesc(1, false);
> TupleDescInitEntry(tupdesc, 1, "hashcode", INT4OID, -1, 0);
>
>> In this way, we can use index_form_tuple() to create a tuple and
>> needn't write a function for hash specially.
>
> I would actually suggest ditching the normal page layout with line pointers
> and IndexTuples altogether. All the entries are fixed size, so you can get
> away with a much simpler structure, and store more entries per page. Storing
> an IndexTuple with one int32 column takes
>
> (sizeof(IndexTupleData) + sizeof(uint32) + sizeof(ItemIdData)) = 16 bytes,
>
> but you only need a pointer to the heap tuple, and the hash code, which is
> just 10 bytes in total. Or 12 if you have to align the hash code to 4 byte
> boundary.
>
> --
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
>

--
Best Regards,
Xiao Meng

DKERC, Harbin Institute of Technology, China
Gtalk: mx(dot)cogito(at)gmail(dot)com
MSN: cnEnder(at)live(dot)com
http://xiaomeng.yo2.cn

"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> I would actually suggest ditching the normal page layout with line
> pointers and IndexTuples altogether.

It would be a bad idea to remove the page header. You need the LSN
(someday hash indexes will obey WAL logging), and removing the page
version number seems pretty imprudent also. I'd be inclined to
stick with the regular header and the existing "special space"
definition. But yeah, what's in between need not necessarily be
regular tuples.

regards, tom lane

On Tue, Jul 15, 2008 at 10:22 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
>> I would actually suggest ditching the normal page layout with line
>> pointers and IndexTuples altogether.
>
> It would be a bad idea to remove the page header. You need the LSN
> (someday hash indexes will obey WAL logging), and removing the page
> version number seems pretty imprudent also. I'd be inclined to
> stick with the regular header and the existing "special space"
> definition. But yeah, what's in between need not necessarily be
> regular tuples.

Agreed.

--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation | fax: 732.331.1301
499 Thornall Street, 2nd Floor | jonah(dot)harris(at)enterprisedb(dot)com
Edison, NJ 08837 | http://www.enterprisedb.com/

On Tue, Jul 15, 2008 at 5:56 AM, Xiao Meng <mx(dot)cogito(at)gmail(dot)com> wrote:
> Hi, hackers.
> I'm working on my gsoc project - improving hash index.

Given the amount of time left for SoC, can you please post to -hackers
your proposed design for review and comments (under a new topic).

--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation | fax: 732.331.1301
499 Thornall Street, 2nd Floor | jonah(dot)harris(at)enterprisedb(dot)com
Edison, NJ 08837 | http://www.enterprisedb.com/