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 jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
