Skip site navigation (1) Skip section navigation (2)

Re: vacuum, performance, and MVCC

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: PFC <lists(at)peufeu(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: vacuum, performance, and MVCC
Date: 2006-06-27 16:29:39
Message-ID: 20060627162939.GI44573@pervasive.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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(at)pervasive(dot)com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

In response to

pgsql-hackers by date

Next:From: Yoshiyuki AsabaDate: 2006-06-27 16:33:48
Subject: Re: SO_SNDBUF size is small on win32?
Previous:From: Tom LaneDate: 2006-06-27 16:28:35
Subject: Re: SO_SNDBUF size is small on win32?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group