Re: [RFC] CLUSTER VERBOSE - Mailing list pgsql-hackers

From Dawid Kuroczko
Subject Re: [RFC] CLUSTER VERBOSE
Date
Msg-id 758d5e7f0703151249o7d74acf5v3d1d73dd39a29ae1@mail.gmail.com
Whole thread Raw
In response to [RFC] CLUSTER VERBOSE  (Grzegorz Jaskiewicz <gj@pointblue.com.pl>)
List pgsql-hackers
On 3/15/07, Grzegorz Jaskiewicz <gj@pointblue.com.pl> wrote:
> I figure - I should start brand new thread for this one - so here you
> go.
>
>
> I am in a need for verbose CLUSTER. Ie. one that would give me
> feedback and progress.
> Because CLUSTER is divided into two major operations, (data
> reordering, index rebuild) - I see it this way:
>
> CLUSTER on I: <index name> T: <table name>, data reordering
> CLUSTER on I: <index name> T: <table name>, index rebuild
>
> and than:
> CLUSTER 10%
> CLUSTER 12% , etc

Well, I'm afraid that would be inconsistent with other VERBOSE
commands (VACUUM VERBOSE), which don't give a progress
indication other than that of specific stage being finished.

I think if you want to add VERBOSE to cluster, it should behave
exactly like all other 'VERBOSE' commands.

And as for progress indication, there has been proposals for more
or less similar feature, like:
http://archives.postgresql.org/pgsql-hackers/2006-07/msg00719.php

As I recall the ideas which caught most traction were
indicating current progress via shared memory (pg_stat_activity)
and a GUC variable which instructs the server to send notices
indicating the progress status. The latter is harder.

I'm afraid creating such a feature 'just for CLUSTER' is not the greatest
idea -- there a lots of other places where having a progress bar would
be a great benefit.  REINDEX, most ALTER TABLEs, CREATE INDEX, even
long running SELECTs, UPDATEs and DELETEs not to mention VACUUM
would equally benefit from it.  I think you will be having hard time trying
to push CLUSTER-specific extension when there is a need for more
generic one.
  Regards,     Dawid


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Proposal: minor SPI interface change
Next
From: Tom Lane
Date:
Subject: pltcl vs. multilib machines