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

Re: HOT patch - version 14

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>, "PostgreSQL-patches" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: HOT patch - version 14
Date: 2007-08-30 19:39:59
Message-ID: 87sl60izg0.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-patches
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

>>> Isn't the extra machination for C.I.C. just useless complication?
>>> What's the point of avoiding creation of new broken HOT chains when
>>> you still have to deal with existing ones?
>
>> IMHO the extra step in C.I.C simplifies the index build.
>
> If you make the change suggested above, I think you don't need to do
> things differently in C.I.C.

It seems to me if you wait out transactions as you come across them you could
end up waiting a whole lot longer than the way it works now where it waits
them all out at the end of the first pass.

>> OK.  So if I get you correctly, you are suggesting to acquire cleanup lock.
>> If we don't get that, we don't to any maintenance work. Otherwise, we prune
>> and repair fragmentation in one go.
>
> Yeah, that's what I'm thinking; then there's no need to track a separate
> page state where we've pruned but not defragmented.

Note that you still need to do it in two steps, you just get to postpone the
pruning work to the same point in time as the defragmenting. You can never
"acquire" the cleanup lock when it comes time to insert a new update version
since the executor still holds references to the original tuple.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

In response to

Responses

pgsql-patches by date

Next:From: korry.douglasDate: 2007-08-30 19:47:24
Subject: Re: enum types and binary queries
Previous:From: Tom LaneDate: 2007-08-30 19:21:28
Subject: Re: enum types and binary queries

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