Re: Alternative variable length structure

The code churn to do this is going to be quite significant, as well a
performance-wise hit perhaps, so it has to be a big win.

---------------------------------------------------------------------------

Jim C. Nasby wrote:
> On Wed, Jun 14, 2006 at 04:21:34PM -0400, Bruce Momjian wrote:
> > Jim C. Nasby wrote:
> > > On Wed, Jun 14, 2006 at 02:53:10PM -0400, Bruce Momjian wrote:
> > > > 
> > > > I assume the conclusion from this email thread is that though the idea
> > > > is interesting, the complexity added would not be worth the saving of a
> > > > few bytes.
> > >  
> > > Anyone do any testing?
> > > 
> > > I'm also wondering if this would be useful to allow fields larger than
> > > 1G.
> > 
> > The submitter showed the pathological case where a single char was
> > stored in a text field, and showed the reduced size (below).  There were
> > no performance numbers given.  It seems like an edge case, especially
> > since we have a "char" type that is a single byte.
> 
> Well, depending on how the patch works I could see it being valuable for
> tables that have a number of 'short' text fields, where short is less
> than 127 bytes.
> 
> I've got some tables like that I can test on, at least to see the size
> difference. Not really sure what a valid performance test would be,
> though...
> 
> I'm wondering if it would be worth trying to organize users to do
> testing of stuff like this. I'm sure there's lots of folks who know how
> to apply a patch and have test data that could benefit from patches like
> this. (I'm assuming this patch didn't place any substantial performance
> penalties into the backend...)
> -- 
> Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
> Pervasive Software      http://pervasive.com    work: 512-231-6117
> vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461
> 

--  Bruce Momjian   http://candle.pha.pa.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +