Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] UUID's as primary keys

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Hallgren <thomas(at)tada(dot)se>, Psql_General <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] UUID's as primary keys
Date: 2006-06-29 13:47:01
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:

> A tuple is just an array of datums, with some header information. The
> problems come when you don't have a tuple anymore, but only the datum,
> like in arguments for functions.
> I think it's more a case that most places that deal with datums simply
> don't know about typmods. For example, the return type of a function
> can only be char, not char(16). If you consider the case of a function
> returning a RAW, the caller will have no way of knowing the typmod,
> they do know the type though.
> To be honest, it seems like a lot of work to save the four bytes of
> overhead for the varlena structure on disk if you're going to need it
> in memory anyway. And anything like RAW(16) which people want for
> UUIDs, if it's going to have a lot of functions associated with it, may
> as well just be a new type. 

For large databases storage density leads directly to speed. Saving four bytes
of overhead on a 16-byte data structure would mean a 20% speed increase. Even
if that's only helpful on a tenth of the columns you're still talking about a
2% speed increase for all queries on the table. A lot of databases use CHAR(1)
for flags. The overhead is even worse there.

> Consider where we currently we have a "Filter Cond" on a "Seq Scan".
> Currently the filter can access the datums directly on the disk page, with
> what you're proposing, it can't.

Well it only can't if the data type has conversion functions. I'm not sure how
complex it would be having pointers that *getattr sometimes return pointers to
the disk page and sometimes return pointers to a palloced copy though.


In response to


pgsql-hackers by date

Next:From: Rodrigo De LeonDate: 2006-06-29 13:48:21
Subject: Re: session id and global storage
Previous:From: Andrew DunstanDate: 2006-06-29 13:44:13
Subject: Re: session id and global storage

pgsql-general by date

Next:From: Thomas HallgrenDate: 2006-06-29 13:54:36
Subject: Re: [GENERAL] UUID's as primary keys
Previous:From: Michael FuhrDate: 2006-06-29 13:36:57
Subject: Re: Script for reading flat file without delimiters

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group