Re: [RFC] indirect toast tuple support - Mailing list pgsql-hackers

From Greg Stark
Subject Re: [RFC] indirect toast tuple support
Date
Msg-id CAM-w4HN+yaV-LmtFrkZvOD8AhAOQN4HZ5WzyM6FaSE6wERafZA@mail.gmail.com
Whole thread Raw
In response to Re: [RFC] indirect toast tuple support  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On Thu, Feb 21, 2013 at 2:32 AM, Greg Stark <stark@mit.edu> wrote:
> On Tue, Feb 19, 2013 at 2:00 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> The only reasonable thing I can see us doing is renaming
>> varattrib_1b_e.va_len_1be into va_type and redefine VARSIZE_1B_E into a
>> switch that maps types into lengths. But I think I would put this off,
>> except placing a comment somewhere, until its gets necessary.
>
> Is there any reason to make it a switch before we actually have two
> types that happen to have the same length?
>
> It might make the code clearer if there was an enum with the (one)
> type listed but as long as all the enum values happen to have the
> value of the length of the struct then it makes heap_form_tuple and
> heap_deform_tuple marginally faster. (unless gcc can optimize away the
> whole switch statement which might be plausible, especially if it's
> just a few ?: expressions)

For what it's worth much of this was discussed at the time. I
originally wrote it as an enum and Tom changed it to a length byte,
specifically for performance reasons, and said we could always change
it back to an enum where some of the values just happened to be equal
to their length if we needed it:

http://www.postgresql.org/message-id/flat/82tzp7bbbh.fsf@mid.bfk.de#82tzp7bbbh.fsf@mid.bfk.de


-- 
greg



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: [RFC] indirect toast tuple support
Next
From: Joachim Wieland
Date:
Subject: Re: posix_fadvise missing in the walsender