Обсуждение: 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.cogito@gmail.com MSN: cnEnder@live.com http://xiaomeng.yo2.cn
Re: Is there anyway to create a TupleDesc with uint32 attribute easily?
От
"Heikki Linnakangas"
Дата:
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@enterprisedb.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.cogito@gmail.com MSN: cnEnder@live.com http://xiaomeng.yo2.cn
"Heikki Linnakangas" <heikki@enterprisedb.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@sss.pgh.pa.us> wrote: > "Heikki Linnakangas" <heikki@enterprisedb.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.harris@enterprisedb.com Edison, NJ 08837 | http://www.enterprisedb.com/
On Tue, Jul 15, 2008 at 5:56 AM, Xiao Meng <mx.cogito@gmail.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.harris@enterprisedb.com Edison, NJ 08837 | http://www.enterprisedb.com/