Re: Controlling Load Distributed Checkpoints

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "PFC" <lists(at)peufeu(dot)com>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Controlling Load Distributed Checkpoints
Date: 2007-06-14 11:40:51
Message-ID: 87d4zywypo.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

"PFC" <lists(at)peufeu(dot)com> writes:

> Anyway, seq-scan on InnoDB is very slow because, as the btree grows (just
> like postgres indexes) pages are split and scanning the pages in btree order
> becomes a mess of seeks. So, seq scan in InnoDB is very very slow unless
> periodic OPTIMIZE TABLE is applied. (caveat to the postgres TODO item
> "implement automatic table clustering"...)

Heikki already posted a patch which goes a long way towards implementing what
I think this patch refers to: trying to maintaining the cluster ordering on
updates and inserts.

It does it without changing the basic table structure at all. On updates and
inserts it consults the indexam of the clustered index to ask if for a
suggested block. If the index's suggested block has enough free space then the
tuple is put there.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2007-06-14 11:45:21 Re: Sorted writes in checkpoint
Previous Message Gregory Stark 2007-06-14 11:30:03 Re: tsearch_core patch: permissions and security issues

Browse pgsql-patches by date

  From Date Subject
Next Message Gregory Stark 2007-06-14 11:45:21 Re: Sorted writes in checkpoint
Previous Message ITAGAKI Takahiro 2007-06-14 09:07:07 Re: DROP TABLE and autovacuum