From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Plan for compressed varlena headers |
Date: | 2007-02-14 17:03:57 |
Message-ID: | 25905.1171472637@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> 1) Replace the VARATT_SIZEP macro with SET_VARLENA_LEN.
If we're going to do this then it's time to play the name game; that is,
pick names we actually like and that work well together. The original
TOAST patch made things a bit messy in this area. We should try to
improve the situation now, not make it worse.
We have the following macro names that are commonly used for varlena
struct access:
VARHDRSZ
VARATT_SIZEP(x)
VARATT_SIZE(x)
VARATT_DATA(x)
VARSIZE(x) equivalent to VARATT_SIZE
VARDATA(x) equivalent to VARATT_DATA
My recollection is that VARHDRSZ, VARSIZE, VARDATA were Berkeley-era
and the other three were added by the TOAST patch. The lack of
consistency is a bit glaring, and having two ways to do the exact
same thing doesn't seem like an improvement.
A first-cut proposal:
VARHDRSZ same as now, ie, size of 4-byte header
VARSIZE(x) for *reading* a 4-byte-header length word
VARDATA(x) same as now, ie, ptr + 4 bytes
SET_VARSIZE(x, len) for *writing* a 4-byte-header length word
We have to remove VARATT_SIZEP anyway to catch unmodified code, and I'd
propose removing VARATT_SIZE and VARATT_DATA too, as they never caught on.
We'll also need names for the macros that can read the length and find
the data of a datum in either-1-or-4-byte-header format. These should
probably be named as variants of VARSIZE and VARDATA, but I'm not sure
what exactly; any thoughts?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2007-02-14 17:06:05 | Re: integer datetimes |
Previous Message | Matt Miller | 2007-02-14 16:52:06 | Re: "anyelement2" pseudotype |