Re: [HACKERS] Frequent Update Project: Design Overview of HOT Updates

Hi, On 11/10/06, Pavan Deolasee <[EMAIL PROTECTED]> wrote: On 11/10/06, Tom Lane <[EMAIL PROTECTED]> wrote: "Pavan Deolasee" < [EMAIL PROTECTED]> writes:> On 11/10/06, Tom Lane <[EMAIL PROTECTED]> wrote:> (2) Isn't this full of race conditions? > I agree, there  could be race  conditions. But

Re: [HACKERS] Frequent Update Project: Design Overview of HOT Updates

> > 1. It doubles the IO (original page + hot page), if the new row would > > have fit into the original page. > > That's an awfully big IF there. Even if you use a fillfactor > of 50% in which case you're paying a 100% performance penalty I don't see where the 50% come from ? That's only

Re: [HACKERS] Frequent Update Project: Design Overview of HOT Updates

On 11/10/06, Tom Lane <[EMAIL PROTECTED]> wrote: "Pavan Deolasee" <[EMAIL PROTECTED]> writes:> On 11/10/06, Tom Lane <[EMAIL PROTECTED]> wrote:> (2) Isn't this full of race conditions? > I agree, there  could be race  conditions. But IMO we can handle those.Doubtless you can prevent races by introd

Re: [HACKERS] Frequent Update Project: Design Overview of HOT Updates

> > I think the vision is that the overflow table would never be very > > large because it can be vacuumed very aggressively. It has only tuples > > that are busy and will need vacuuming as soon as a transaction ends. > > Unlike the main table which is mostly tuples that don't need > > vacuumi

Re: [HACKERS] Frequent Update Project: Design Overview of HOT Updates

Hi,I think the vision is that the overflow table would never be very large because it can be vacuumed very aggressively. It has only tuples that are busyand will need vacuuming as soon as a transaction ends. Unlike the main tablewhich is mostly tuples that don't need vacuuming. Thats right. vacuum

Re: [HACKERS] Frequent Update Project: Design Overview of HOT Updates

"Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes: > 1. It doubles the IO (original page + hot page), if the new row would > have fit into the original page. That's an awfully big IF there. Even if you use a fillfactor of 50% in which case you're paying a 100% performance penalty *al

Re: [HACKERS] Frequent Update Project: Design Overview of HOT Updates

On 11/10/06, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: Tom Lane wrote:> (Actually, the assumption that you can throw an additional back-pointer> into overflow tuple headers is the worst feature of this proposal in> that regard --- it's really not that easy to support multiple header > formats.)

Re: [HACKERS] Frequent Update Project: Design Overview of HOT Updates

> > As more UPDATEs take place these tuple chains would grow, making > > locating the latest tuple take progressively longer. > More generally, do we need an overflow table at all, rather > than having these overflow tuples living in the same file as > the root tuples? As long as there's a b

Re: [HACKERS] Frequent Update Project: Design Overview of HOT Updates

Tom Lane wrote: "Pavan Deolasee" <[EMAIL PROTECTED]> writes: Yes. The last bit in the t_infomask is used up to mark presence of overflow tuple header. But I believe there are few more bits that can be reused. There are three bits available in the t_ctid field as well (since ip_posid needs maximu

Re: [HACKERS] Frequent Update Project: Design Overview of HOT Updates

On 11/10/06, Tom Lane <[EMAIL PROTECTED] > wrote: "Pavan Deolasee" <[EMAIL PROTECTED]> writes:> Yes. The last bit in the t_infomask is used up to mark presence of overflow > tuple header. But I believe there are few more bits that can be reused. > There are three bits available in the t_ctid field

Re: [HACKERS] Frequent Update Project: Design Overview of HOT Updates

"Pavan Deolasee" <[EMAIL PROTECTED]> writes: > On 11/10/06, Tom Lane <[EMAIL PROTECTED]> wrote: > (2) Isn't this full of race conditions? > I agree, there could be race conditions. But IMO we can handle those. Doubtless you can prevent races by introducing a bunch of additional locking. The qu

Re: [HACKERS] Frequent Update Project: Design Overview of HOT Updates

On 11/10/06, Tom Lane <[EMAIL PROTECTED]> wrote: "Pavan Deolasee" <[EMAIL PROTECTED]> writes:> On 11/10/06, Josh Berkus < josh@agliodbs.com> wrote: >> I believe that's the "unsolved technical issue" in the prototype, unless>> Pavan has solved it in the last two weeks.   Pavan?>>> When an overflow

Re: [HACKERS] Frequent Update Project: Design Overview of HOT Updates

"Pavan Deolasee" <[EMAIL PROTECTED]> writes: > On 11/10/06, Josh Berkus wrote: >> I believe that's the "unsolved technical issue" in the prototype, unless >> Pavan has solved it in the last two weeks. Pavan? >> > When an overflow tuple is copied back to the main heap, the overflow tuple > is >

Re: [HACKERS] Frequent Update Project: Design Overview of HOT Updates

On 11/10/06, Josh Berkus wrote: Tom,> Actually, you omitted to mention the locking aspects of moving tuples> around --- exactly how are you going to make that work without breaking> concurrent scans?I believe that's the "unsolved technical issue" in the prototype, unless Pavan h

Re: [HACKERS] Frequent Update Project: Design Overview of HOT Updates

Tom, > Actually, you omitted to mention the locking aspects of moving tuples > around --- exactly how are you going to make that work without breaking > concurrent scans? I believe that's the "unsolved technical issue" in the prototype, unless Pavan has solved it in the last two weeks. Pavan?

Re: [HACKERS] Frequent Update Project: Design Overview of HOT Updates

"Simon Riggs" <[EMAIL PROTECTED]> writes: > As more UPDATEs take place these tuple chains would grow, making > locating the latest tuple take progressively longer. This is the part that bothers me --- particularly the random-access nature of the search. I wonder whether you couldn't do something

Re: [HACKERS] Frequent Update Project: Design Overview of HOT Updates

Simon, > If we perform an update that meets the HOT criteria then we put the > new version into the overflow relation; we describe this as a HOT > UPDATE. If we perform an update that does not meet the criteria, then we > carry on with the existing/old MVCC behaviour; we describe this as a > non-H

Re: [HACKERS] Frequent Update Project: Design Overview of HOT Updates

Nice idea, just one question: On Thu, Nov 09, 2006 at 05:13:16PM +, Simon Riggs wrote: > Behavioural Characteristics > --- > > With HOT, it is easily possible that the chain of prior versions spans > many blocks. The chain always starts with the block of the root tuple

[HACKERS] Frequent Update Project: Design Overview of HOT Updates

Design Overview of HOT Updates -- The objective is to increase the speed of the UPDATE case, while minimizing the overall negative effects of the UPDATE. We refer to the general requirement as *Frequent Update Optimization*, though this design proposal is for Heap Overf