Re: (WIP) VACUUM REWRITE - CLUSTER by ctid - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: (WIP) VACUUM REWRITE - CLUSTER by ctid
Date
Msg-id 4AE15355.2070509@enterprisedb.com
Whole thread Raw
In response to (WIP) VACUUM REWRITE - CLUSTER by ctid  (Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Responses Re: (WIP) VACUUM REWRITE - CLUSTER by ctid
List 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


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: table corrupted
Next
From: Dimitri Fontaine
Date:
Subject: Re: plpgsql EXECUTE will not set FOUND