On Fri, May 19, 2006 at 12:43:05PM +0100, Simon Riggs wrote: > We need to test "SELECT aid from accounts" also, or some other scenarios > where the data is as uncompressible as possible. We should also try this > on a table where the rows have been inserted by different transactions, > so that the xmin value isn't the same for all tuples. We need to see if > there are cases where this causes a performance regression rather than > gain.
AFAIK, the xmin is not included in the sort. The only thing is maybe the ctid which is used in updates. Actually repeating the above tests but doing: select xmin,xmax,cmin,cmax,ctid,* from <blah> Would be interesting. Even that would be compressable though. Thinking about it, we're storing and compressing HeapTuples right. There are a few fields there that would compress really well. t_tableOid t_len (if not vairable length fields) t_natts Even t_hoff and the bitmask if the patterns of NULLs don't vary much between rows. > We still need to examine memory usage. Jim's testing so far is done on > already sorted data, so only uses 1 out of 715 tapes. If we did utilise > a much larger number of tapes, we could face difficulties with the > memory used during decompression. I'm going to see if I can make some changes to track maximum memory usage per tape. Have a nice day, -- Martijn van Oosterhout <email@example.com> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate.
Description: Digital signature