RE: [QUESTIONS] Pre-Estimating Penalty for variable length fields - Mailing list pgsql-hackers

From Jackson, DeJuan
Subject RE: [QUESTIONS] Pre-Estimating Penalty for variable length fields
Date
Msg-id F10BB1FAF801D111829B0060971D839F26D92E@dal_cps.cpsgroup.com
Whole thread Raw
List pgsql-hackers
> How would one go about estimating the performance penalty for variable
> length fields?...
>
> Is it dependant on the number of records?
> In practice, is it swallowed up by the performance of the internet?
> Exactly when is the performance hit?
> IE  Does it happen when returning those fields, or just on comparisons
> or what?
> What, if any, other penalties come with text fields?
> EG  In msql, they can't be indexed...
>
> I'm trying to decide if it's worth doing all the work of data
> integrity and
> such to have fixed length character fields, or if I should just make
> 'em
> all text and be done with it.
>
> Probably no more than 1000 records, but a lot of text fields, for
> address,
> phone, etc.
>
> Thanks for any discussion on this, and I'll try and collate it into
> something suitable for adding to the docs/FAQ.
>
When the backend access a specific field it need to calculate where that
field is in the DISK, PAGE, and/or ROW.  This means that all the fields
on a ROW after the first variable length field has the access overhead
of resolving the length of the variable length field.  This could be
done once or for each field accessed (I'd have to look at the code to be
sure).

You can most likely get firm numbers from the HACKERS list.

        -DEJ

pgsql-hackers by date:

Previous
From: "Thomas G. Lockhart"
Date:
Subject: Re: on patch for close_ps() func. in geo_ops.c
Next
From: ocie@paracel.com
Date:
Subject: Re: [HACKERS] OK to send e-mail?