Re: GUIDs
От | David Wheeler |
---|---|
Тема | Re: GUIDs |
Дата | |
Msg-id | 6EC043EB-17C2-11D8-9545-0003931A964A@kineticode.com обсуждение исходный текст |
Ответ на | Re: GUIDs (Doug McNaught <doug@mcnaught.org>) |
Список | pgsql-general |
On Saturday, November 15, 2003, at 05:26 PM, Doug McNaught wrote: > I think if I were in your place, I'd store them as TEXT fields using > either the base64 or hex representation. That was my original plan. But because the hex and base64 representations are 32 bytes instead of 16, it ends up being a lot less efficient. Josh Berkus explains it to me like this: <agliodbs> I mean, think of, for example, many-to-many join tables, or tree tables, with millions of rows but just to id columns <agliodbs> going from 32 bytes per row to 64 bytes will almost double the size of the table and all of its indexes <agliodbs> for example, let's take the join table/index example: 1000000 rows, with 2 ID colmuns <agliodbs> now, usling a 16byte number, you have about 40bytes per row (16+16+overhead) <agliodbs> that's 40mb to load the table/index into memory <agliodbs> but if you go with 32chars, that's about 76mb ... or abut 120mb for unicode <agliodbs> hopefully you're not loading the whole thing into memory often, but sometimes seq scans are necessary, and as much as 1/3 of the table could end up in memory <agliodbs> in addition to the memory load, it takes longer to get 40 mb off disk than it does to take 13mb <agliodbs> and longer to sync it to disk, and longer to vacuum it So I'm inclined, I think, to use BYTEA as Peter originally suggested (I can't get pguuid to compile for PostgreSQL 7.3.3 or 7.4RC2) and convert it to other representations as needed on the API. Regards, David -- David Wheeler AIM: dwTheory david@kineticode.com ICQ: 15726394 http://www.kineticode.com/ Yahoo!: dew7e Jabber: Theory@jabber.org Kineticode. Setting knowledge in motion.[sm]
В списке pgsql-general по дате отправления: