From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
Cc: | Josh Kupershmidt <schmiddy(at)gmail(dot)com>, Leonardo Francalanci <m_lists(at)yahoo(dot)it>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: I: About "Our CLUSTER implementation is pessimal" patch |
Date: | 2010-09-29 12:44:27 |
Message-ID: | 1285764117-sup-6831@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Excerpts from Itagaki Takahiro's message of mié sep 29 01:25:38 -0400 2010:
> To be exact, It's very complex.
> During reconstructing tables, it requires about twice disk space of
> the old table (for sort tapes and the new table).
> After sorting the table, CLUSTER performs REINDEX. We need
> {same size of the new table} + {twice disk space of the new indexes}.
> Also, new relations will be the same sizes of old relations if they
> have no free spaces.
Aren't the old table and indexes kept until transaction commit, though?
So during the reindex you still keep the old copy of the table and
indexes around, thus double space. The only space difference would be
extra free space in the old table, tuples older than OldestXmin, and
fillfactor changes.
> So, I think "twice disk space of the sum of table and indexes" would be
> the simplest explanation for safe margin.
Agreed.
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-09-29 13:00:47 | Re: security hook on table creation |
Previous Message | Shigeru HANADA | 2010-09-29 12:43:09 | Re: patch: SQL/MED(FDW) DDL |