On Tue, Jun 27, 2006 at 10:42:54AM +0200, PFC wrote: > Also, I insist (again) that there is a lot to gain by using a bit of > compression on the data pages, even if it's very simple compression like > storing the new version of a row as a difference from the previous version > (ie. only store the columns that changed). > I think DB2 stores the latest version entirely, and stores the > previous versions as a delta. This is more efficient. This would only help on tables that:
have many columns[1] are frequently updated the updates normally touch few columns [1] I'm assuming that un-changed toasted fields keep the same pointer I'm doubtful that that case is common enough to warrant the amount of work that would be involved in doing this. I think it might be useful to consider ways to make vertical partitioning easier, since that's the common means to reduce the impact of these scenarios. > In the case of tables containing TEXT values, these could also get > TOASTed. When an update does not modify the TOASTed columns, it would be > nice to simply be able to keep the reference to the TOASTed data instead > of decompressing it and recompressing it. Or is it already the case ? Hopefully it is, but I'm not sure... something that would be good is a means to force fields to be toasted sooner than when the tuple is bigger than 2k, because that'd be a very easy way to get gains from vertical partitioning. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend