Alvaro Herrera wrote: > > > >> > 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); > > > > Wow, we optimized length(). OK, will run the test with > > substring(t,1,1). > > Be careful about the compression! It might be a good idea to run the > test once with the column set to uncompressible (SET STORAGE EXTERNAL?), > and again with it as compressible.
My test uses random data, which I figured was a close to real-world as I could get, and I have a test that makes sure the data was pushed to the TOAST table. Should I still try EXTERNAL? -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings