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
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 |
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 |