From: | Gregory Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Gregory Stark <gsstark(at)mit(dot)edu>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Subject: | Re: Fixed length data types issue |
Date: | 2006-09-09 21:28:44 |
Message-ID: | 8764fwwwz7.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> > The performance costs of that seem pretty daunting, however, especially when
> > you reflect that simply stepping over a varlena field would require
> > memcpy'ing its length word to someplace.
>
> I think if you give up on disk and in-memory representations being the same
> then there are ways of finessing that. For example you could have all the
> lengths together in the header prior to the variable length fields.
Hm, this might have nice cache effects when reading in a tuple too. Since all
the lengths would likely fit in a single cache line and probably the same
cache line as the null bitmap even it means you can find all the offsets
without actually having to bring in the rest of the tuple into the processor.
I don't think that alone would be enough to outweigh the costs of having to
convert to an in-memory representation though. Even if that was still just a
pointer to the buffer memory in the simple case.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2006-09-09 21:58:35 | Move completed ... |
Previous Message | Martijn van Oosterhout | 2006-09-09 20:45:41 | Re: log_duration is redundant, no? |