Re: Introducing an advanced Frequent Update Optimization - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Introducing an advanced Frequent Update Optimization
Date
Msg-id 1162877475.30200.208.camel@silverbirch.site
Whole thread Raw
In response to Re: Introducing an advanced Frequent Update Optimization  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
List pgsql-hackers
On Tue, 2006-11-07 at 13:02 +0900, ITAGAKI Takahiro wrote:
> "Simon Riggs" <simon@2ndquadrant.com> wrote:
> 
> > EnterpriseDB has been running a research project to improve the
> > performance of heavily updated tables. We have a number of approaches
> > prototyped and we'd like to discuss the best of these now on -hackers
> > for community input and patch submission to PostgreSQL core.
> 
> I'm very interested in your proposal! NTT is also working for OLTP workloads,
> especially on improvements of VACUUM. Maybe we have similar problems.

Seems very likely.

> I made a prototypes of Heap-needs-vacuum-bitmap and per-entry-index-deletion.
> The test result shows that it saves vacuuming time. I'm refining and making
> it robust now.
> 
> We can make use of the present structures with the approach, so I have
> thought it is a relatively good direction. However, you seem to propose
> a whole new storage engine or on-disk-structure. Do you have any viewpoints
> that some kinds of extending-VACUUM approach are not enough?

Thats been something we have considered, with good results.

We still need to VACUUM, but in a modified way.

> It would be very nice if you could give us some more background.

Certainly. We'll be posting a full design description on Wednesday; I'm
just editing that now.

--  Simon Riggs              EnterpriseDB   http://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: "Brendan Jurd"
Date:
Subject: Re: Indicate disabled triggers in \d
Next
From: "Brendan Jurd"
Date:
Subject: Uncleared result sets in describeOneTableDetails()