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. +
