Re: Re: Call for platforms - Mailing list pgsql-hackers
From | Mark Knox |
---|---|
Subject | Re: Re: Call for platforms |
Date | |
Msg-id | 3AC0FCD4.29650.FABF4C1@localhost Whole thread Raw |
In response to | Re: Re: Call for platforms (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Re: Call for platforms
Re: Re: Call for platforms |
List | pgsql-hackers |
-----BEGIN PGP SIGNED MESSAGE----- On 26 Mar 2001, at 23:14, Tom Lane wrote: > "Mark Knox" <segfault@hardline.org> writes: > > On 25 Mar 2001, at 16:07, Tom Lane wrote: > >> Does that database have any user-created relations in it, or is it > >> just a virgin database? > > > Totally virgin. I created it just for that select you wanted. > > Okay. Would you create a couple of random tables in it and do the > select again? I want to see what ctid looks like in a user-created > table. Sure. I created two tables called 'test1' and 'test2'. Test1 has a single field 'field1' of type int4. Test2 has two fields 'field1' and 'field2' of types char(200) and int4 respectively. Here are the results: postgres=> select p1.oid,attrelid,relname,attname,attlen,attalign,attbyval from pg_attribute p1, pg_class p2 where atttypid = 27 and p2.oid = attrelid order by 1; oid|attrelid|relname |attname|attlen|attalign|attbyval - -----+--------+--------------+-------+------+--------+-------- 16401| 1247|pg_type |ctid | 6|i |f 16415| 1262|pg_database |ctid | 6|i |f 16439| 1255|pg_proc |ctid | 6|i |f 16454| 1260|pg_shadow |ctid | 6|i |f 16464| 1261|pg_group |ctid | 6|i |f 16486| 1249|pg_attribute |ctid | 6|i |f 16515| 1259|pg_class |ctid | 6|i |f 16526| 1215|pg_attrdef |ctid | 6|i |f 16537| 1216|pg_relcheck |ctid | 6|i |f 16557| 1219|pg_trigger |ctid | 6|i |f 16572| 16567|pg_inherits |ctid | 8|i |f 16593| 16579|pg_index |ctid | 8|i |f 16610| 16600|pg_statistic |ctid | 8|i |f 16635| 16617|pg_operator |ctid | 8|i |f 16646| 16642|pg_opclass |ctid | 8|i |f 16678| 16653|pg_am |ctid | 8|i |f 16691| 16685|pg_amop |ctid | 8|i |f 16873| 16867|pg_amproc |ctid | 8|i |f 16941| 16934|pg_language |ctid | 8|i |f 16953| 16948|pg_largeobject|ctid | 8|i |f 16970| 16960|pg_aggregate |ctid | 8|i |f 17038| 17033|pg_ipl |ctid | 8|i |f 17051| 17045|pg_inheritproc|ctid | 8|i |f 17067| 17058|pg_rewrite |ctid | 8|i |f 17079| 17074|pg_listener |ctid | 8|i |f 17090| 17086|pg_description|ctid | 8|i |f 17206| 17201|pg_toast_1215 |ctid | 8|i |f 17221| 17216|pg_toast_17086|ctid | 8|i |f 17236| 17231|pg_toast_1255 |ctid | 8|i |f 17251| 17246|pg_toast_1216 |ctid | 8|i |f 17266| 17261|pg_toast_17058|ctid | 8|i |f 17281| 17276|pg_toast_16600|ctid | 8|i |f 17301| 17291|pg_user |ctid | 8|i |f 17314| 17309|pg_rules |ctid | 8|i |f 17327| 17322|pg_views |ctid | 8|i |f 17342| 17335|pg_tables |ctid | 8|i |f 17355| 17350|pg_indexes |ctid | 8|i |f 18724| 18721|test1 |ctid | 8|i |f 18735| 18731|test2 |ctid | 8|i |f (39 rows) > > I suspect it might be an alignment problem > > Sort of. I am suspicious that sizeof(ItemPointerData) is returning 8 > rather than 6 as one might expect. Maybe it's padding the structure to a dword boundary? ARM is notorious for such things.. I will rebuild it with __attribute__((packed)) on the struct and see if the size changes.. -----BEGIN PGP SIGNATURE----- Version: N/A iQCVAwUBOsFDJP+IdJuhyV9xAQEKxQP/YJXTxZppLd7ECk4BSwDZaStP4+bE6acc StT//i/drdPC53DDWqiXLGA0bS384EXxyjvvaO1bTXzVFU/3+X/pY6YN/G3HMoah dbCXRli2Y57yansf1WaVmK1lhiAqLy3iGYFp2nZvO1Sl1u+ba89HtV+G+iaKZSTr U+HWTU3nnOM= =vkY+ -----END PGP SIGNATURE-----
pgsql-hackers by date: