From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: (WIP) VACUUM REWRITE - CLUSTER by ctid |
Date: | 2009-10-23 06:55:17 |
Message-ID: | 4AE15355.2070509@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Itagaki Takahiro wrote:
> I'm working on alternative version of VACUUM FULL, which is
> like CLUSTER but sort tuples in ctid order without index.
> The original discussion is here:
> [HACKERS] Feedback on getting rid of VACUUM FULL
> http://archives.postgresql.org/pgsql-hackers/2009-09/msg01047.php
>
> WIP patch attached. I have some questions over the development:
>
> 1. Syntax: I choose "CLUSTER tbl WITHOUT INDEX" for the syntax,
> but it is debatable. What syntax is the best?
> VACUUM REWRITE? CLUSTER ORDER BY ctid? or replace VACUUM FULL?
I got the impression that replacing VACUUM FULL is the most popular
opinion. I like VACUUM REWRITE myself, except that it would require
making REWRITE a reserved keyword. I don't like tacking this onto
CLUSTER, particularly not with "ORDER BY ctid". ctids are an
implementation detail most users don't care about, and ORDER BY sounds
like it's sorting something, but it's not.
> 2. Superclass of HeapScanDesc and IndexScanDesc:
> We don't have an abstraction layer of HeapScanDesc and IndexScanDesc,
> but the layer is useful for this purpose. Is it reasonable?
> It is partially implemented as genam_beginscan() family in the patch.
I don't think it's really necessary. You might as well put a few "if
(indexOid)" clauses directly into copy_heap_data.
> 3. Should we allow "ctid" as a default clustered index?
> We could assume "ctid" as a virtual index. The syntax for it
> might be "ALTER TABLE tbl CLUSTER ON COLUMN ctid" or so.
Isn't that the same as having no clustering index? We already have
"ALTER TABLE tbl SET WITHOUT CLUSTER".
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2009-10-23 08:24:43 | Re: plpgsql EXECUTE will not set FOUND |
Previous Message | Jeff Davis | 2009-10-23 05:17:33 | pre-proposal: type interfaces |