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: | 87mzbwt6p6.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-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.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Hallgren | 2006-06-29 13:54:36 | Re: [GENERAL] UUID's as primary keys |
Previous Message | Michael Fuhr | 2006-06-29 13:36:57 | Re: Script for reading flat file without delimiters |
From | Date | Subject | |
---|---|---|---|
Next Message | Rodrigo De Leon | 2006-06-29 13:48:21 | Re: session id and global storage |
Previous Message | Andrew Dunstan | 2006-06-29 13:44:13 | Re: session id and global storage |