Re: Alternative variable length structure

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Alternative variable length structure
Date: 2006-06-15 03:04:52
Message-ID: 16730.1150340692@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Neil Conway <neilc(at)samurai(dot)com> writes:
> On Wed, 2006-06-14 at 16:56 -0400, Bruce Momjian wrote:
>> The code churn to do this is going to be quite significant

> Why do you say that? Although the original patch posted to implement
> this was incomplete, it certainly wasn't very large.

IIRC, the original idea would have forced code changes on every existing
varlena datatype ... not just those in our source tree, but outside
users' custom types as well. You'd need a really *serious* gain to
justify that.

The second idea was to leave existing varlena types as-is and invent
a set of "small text" etc datatypes alongside them. This is simply
ugly (shades of Oracle's varchar2), and again there wasn't really an
adequate case made why we should burden users with extra complexity.

The variant I could have supported was making a "2-byte-header" class of
types and using it just for the few types where it would be sufficient
(numeric and inet, basically). That would be transparent to everyone.
Whether it's worth the trouble is not clear given that it'd only help a
few datatypes, but would add cycles in critical inner loops in places
like heap_deformtuple.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-06-15 04:05:38 Test request for Stats collector performance improvement
Previous Message Qingqing Zhou 2006-06-15 02:58:53 Re: Spinlocks, yet again: analysis and proposed patches