Skip site navigation (1)
Skip section navigation (2)
Peripheral Links
Header And Logo
|
Site Navigation
Re: [GENERAL] UUID's as primary keys
- From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
- To: Greg Stark <gsstark(at)mit(dot)edu>
- Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, Thomas Hallgren <thomas(at)tada(dot)se>, Psql_General <pgsql-hackers(at)postgresql(dot)org>
- Subject: Re: [GENERAL] UUID's as primary keys
- Date: Wed, 28 Jun 2006 23:23:17 -0400
Greg Stark <gsstark(at)mit(dot)edu> writes: > Hm, so it could be stored on disk without the length header as long as > the length header is added to the in-memory representation? I don't > think the type system has hooks for reading and storing data to disk > though. No, it doesn't, and we'd pay a nonzero price for allowing that. Currently the executor doesn't have to care (much) about whether a tuple is on-disk or in-memory --- the individual datums look the same either way. Allowing them to be different would force a lot of format conversion steps that currently need not happen. regards, tom lane
- Follow-Ups:
- Re: [GENERAL] UUID's as primary keys
- From: Greg Stark
- Re: [GENERAL] UUID's as primary keys
- References:
- Re: [GENERAL] UUID's as primary keys
- From: Greg Stark
- Re: [GENERAL] UUID's as primary keys
- Prev by Date: Re: optimizing constant quals within outer joins
- Next by Date: Re: Fixed length datatypes. WAS [GENERAL] UUID's as
- Previous by thread: Re: [GENERAL] UUID's as primary keys
- Next by thread: Re: [GENERAL] UUID's as primary keys
- Indexes: