"Bruce Momjian" <[EMAIL PROTECTED]> writes:

> Gregory Stark wrote:
>> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>> > I tested TOAST using a method similar to the above method against CVS
>> > HEAD, with default shared_buffers = 32MB and no assert()s.  I created
>> > backends with power-of-2 seetings for TOAST_TUPLES_PER_PAGE (4(default),
>> > 8, 16, 32, 64) which gives TOAST/non-TOAST breakpoints of 2k(default),
>> > 1k, 512, 256, and 128, roughly.
>> >
>> > The results are here:
>> >
>> >    http://momjian.us/expire/TOAST/
>> >
>> > Strangely, 128 bytes seems to be the break-even point for TOAST and
>> > non-TOAST, even for sequential scans of the entire heap touching all
>> > long row values.  I am somewhat confused why TOAST has faster access
>> > than inline heap data.

Is your database initialized with C locale? If so then length(text) is
optimized to not have to detoast:

        if (pg_database_encoding_max_length() == 1)
                PG_RETURN_INT32(toast_raw_datum_size(str) - VARHDRSZ);

Also, I think you have to run this for small datasets like you have well as
large data sets where the random access seek time of TOAST will really hurt.

  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 [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to