Thread: Packed Varlena Update (v21)
This is just an update against CVS because there was a conflict due to the configure Kerberos change. There is one bug fix in indextuple.c. I need to think a bit on how to write a regression test to test it. I'll try to attach the patch as an attachment this time, crossing my fingers. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
Attachment
stark <stark@enterprisedb.com> writes:
> [ packed varlena patch ]
Applied with revisions. Waiting to see how badly the buildfarm
complains ;-) ... but I did test on little- and big-endian machines
with different MAXALIGN values.
regards, tom lane
I wrote:
> stark <stark@enterprisedb.com> writes:
>> [ packed varlena patch ]
> Applied with revisions.
Forgot to mention: one of the revisions was to not add the "sizes.sql"
test, because the output was platform-dependent and is likely to get
more so if any ability to change the toast thresholds gets put in.
Can we improve that test to not expose any platform-dependent numbers?
regards, tom lane
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > I wrote: >> stark <stark@enterprisedb.com> writes: >>> [ packed varlena patch ] > >> Applied with revisions. > > Forgot to mention: one of the revisions was to not add the "sizes.sql" > test, because the output was platform-dependent and is likely to get > more so if any ability to change the toast thresholds gets put in. > Can we improve that test to not expose any platform-dependent numbers? I had imagined that we would have two versions of output files. Other than 32-bit versus 64-bit what other platform-dependent variations enter into it? I'll look at it again on a 64-bit machine, but probably not for another week. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> Forgot to mention: one of the revisions was to not add the "sizes.sql"
>> test, because the output was platform-dependent and is likely to get
>> more so if any ability to change the toast thresholds gets put in.
>> Can we improve that test to not expose any platform-dependent numbers?
> I had imagined that we would have two versions of output files. Other than
> 32-bit versus 64-bit what other platform-dependent variations enter into it?
If there'd be only two then I'd be all right with it, but I'm worried
that making TOAST thresholds configurable would result in lots more
possible outputs than that.
BTW, another area that should be kept on the TODO list is to see whether
it makes sense to support 1-byte-header format for array elements.
I looked at that briefly while reviewing the patch but decided it was a
large additional chunk of work and not on the critical path.
regards, tom lane
Added to TODO:
o Allow single-byte header storage for arrays
---------------------------------------------------------------------------
Tom Lane wrote:
> Gregory Stark <stark@enterprisedb.com> writes:
> > "Tom Lane" <tgl@sss.pgh.pa.us> writes:
> >> Forgot to mention: one of the revisions was to not add the "sizes.sql"
> >> test, because the output was platform-dependent and is likely to get
> >> more so if any ability to change the toast thresholds gets put in.
> >> Can we improve that test to not expose any platform-dependent numbers?
>
> > I had imagined that we would have two versions of output files. Other than
> > 32-bit versus 64-bit what other platform-dependent variations enter into it?
>
> If there'd be only two then I'd be all right with it, but I'm worried
> that making TOAST thresholds configurable would result in lots more
> possible outputs than that.
>
> BTW, another area that should be kept on the TODO list is to see whether
> it makes sense to support 1-byte-header format for array elements.
> I looked at that briefly while reviewing the patch but decided it was a
> large additional chunk of work and not on the critical path.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
"Bruce Momjian" <bruce@momjian.us> writes: > Added to TODO: > > o Allow single-byte header storage for arrays Fwiw this is "single-byte header storage for varlena array *elements*" The arrays themselves already get the packed varlena treatment. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
Thanks, that was a distinction I didn't know. TODO updated:
o Allow single-byte header storage for array elements
---------------------------------------------------------------------------
Gregory Stark wrote:
>
> "Bruce Momjian" <bruce@momjian.us> writes:
>
> > Added to TODO:
> >
> > o Allow single-byte header storage for arrays
>
> Fwiw this is "single-byte header storage for varlena array *elements*"
>
> The arrays themselves already get the packed varlena treatment.
>
> --
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +