Re: vacuum row? - Mailing list pgsql-hackers

From A.M.
Subject Re: vacuum row?
Date
Msg-id 34079.216.41.12.254.1151330220.squirrel@webmail.webopticon.org
Whole thread Raw
In response to Re: vacuum row?  ("Mark Woodward" <pgsql@mohawksoft.com>)
List pgsql-hackers
On Mon, June 26, 2006 9:37 am, Mark Woodward wrote:
>> On 6/24/06, Mark Woodward <pgsql@mohawksoft.com> wrote:
>>
>>> I originally suggested a methodology for preserving MVCC and everyone
>>> is confusing it as update "in place," this isnot what I intended.
>>
>> Actually, you should've presented your idea as performing MVCC the way
>> Firebird does... the idea is basically the same.  Doing some research
>> never hurts... especially with this crowd.
>
> Is it really nessisary make personal comments like this? Lets discuss
> "ideas" not personalities or people.
>
>
> The whole issue was how to address updates steadily degrading
> performance. I wanted to brainstorm the issue and find a solution. I
> tossed out a first guess at an algorithm to start the ball rolling.
>
> Was it perfect? No. Was it intended to be? no. It was intended to spark a
>  discussion, get people, first to recognize the problem, and then to
> think about possible solutions.
>
> I find that this, while chaotic, usually finds the best solutions. There
> are a lot of good and smart people here who understand this process and see
> it for what it is. Unfortunately, some don't.
>
> It isn't about "research," per se, because it is assumed that we all know
>  the various issues involved to some degree. It is about using the
> collective knowledge of the group and coming up with an answer.

Actually, it is. There are plenty of databases that don't need an
expensive separate process to clean out dead-space, so it would be wise to
see how those alternatives handle MVCC to see what this project can glean
from other's work- that is the point of open source.

Firebird, for example, has a half-dozen articles on how it handles MVCC
and dead tuples. In particular, it puts the "vacuum" burden on the
sessions and fires off a separate cleanup ("sweep") thread. After all,
what will know better than the transaction itself on what needs to be
cleaned up?

Linking goodness:
http://www.firebirdsql.org/doc/whitepapers/fb_vs_ibm_vs_oracle.htm
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_expert4

-M




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: vacuum, performance, and MVCC
Next
From: Devrim GUNDUZ
Date:
Subject: Re: Anyone still care about Cygwin? (was Re: [CORE] GPL