Re: [RFC] indirect toast tuple support

From: Greg Stark <stark(at)mit(dot)edu>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [RFC] indirect toast tuple support
Date: 2013-02-21 02:32:13
Message-ID: CAM-w4HOfzsSyiu7r_zWUFDBTdJzV9ePJYiRRouJ9hNavRPpzGw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 19, 2013 at 2:00 PM, Andres Freund <andres(at)2ndquadrant(dot)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)

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2013-02-21 02:37:31 Re: [RFC] indirect toast tuple support
Previous Message Josh Kupershmidt 2013-02-21 02:28:42 Re: BUG #7873: pg_restore --clean tries to drop tables that don't exist