>>> Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> Additional processing information as discussed later in the thread
can
> now be added easily, but I think there was no consensus on what
exactly
> to print.
Since I use CLUSTER almost exclusively to eliminate bloat, I'd like to
see the before a
Jim Cox wrote:
A patch s/b attached which adds a "VERBOSE" option to the CLUSTER command as
mentioned in the following TODO item for CLUSTER: "Add VERBOSE option
to report tables as they are processed, like VACUUM VERBOSE".
I have committed this version of your patch, but moving the VERBOSE
op
On Monday 13 October 2008 16:45:35 Joshua Drake wrote:
> On Mon, 13 Oct 2008 15:34:04 -0500
>
> "Kevin Grittner" <[EMAIL PROTECTED]> wrote:
> > ccdev=# select pg_total_relation_size('"DbTranImageStatus"');
> > pg_total_relation_size
> >
> > 253952
> > (1 r
On Mon, 13 Oct 2008 15:34:04 -0500
"Kevin Grittner" <[EMAIL PROTECTED]> wrote:
> ccdev=# select pg_total_relation_size('"DbTranImageStatus"');
> pg_total_relation_size
>
> 253952
> (1 row)
>
> ccdev=# cluster "DbTranImageStatus";
> CLUSTER
> ccdev=# sele
>>> Tom Lane <[EMAIL PROTECTED]> wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Tom Lane <[EMAIL PROTECTED]> writes:
>>> Short of actually running an ANALYZE, I'm not seeing a good way to
>>> derive the same number it derives.
>
>> Well we could print the _old_ value at least.
>
> +1 ...
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> Short of actually running an ANALYZE, I'm not seeing a good way to
>> derive the same number it derives.
> Well we could print the _old_ value at least.
+1 ... seems an appropriate amount of effort for the likely
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> I agree with that. I like the idea of printing a message though -- we should
>> just have it print the correlation for now and when we improve the stats
>> we'll
>> print the new metric.
>
> Short of actually runn
Gregory Stark <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> Until we have a better metric for "sortedness", my earlier suggestion to
>> print
>> it was probably a bad idea. If anything, should probably print the same
>> correlation metric that ANALYZE calculates,
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Jim Cox wrote:
>> On Mon, Oct 13, 2008 at 8:30 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>>> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>>>
>>> It'd be possible to count the number of order reversals during the
>>> indexscan, ie the number of tup
On Mon, 2008-10-13 at 08:30 -0400, Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > No, I was thinking of something along the lines of:
> > INFO: clustering "public.my_c"
> > INFO: complete, was 33%, now 100% clustered
> > The only such measure that we have is the correlation,
Jim Cox wrote:
On Mon, Oct 13, 2008 at 8:30 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
No, I was thinking of something along the lines of:
INFO: clustering "public.my_c"
INFO: complete, was 33%, now 100% clustered
The only such measure that we have
On Mon, Oct 13, 2008 at 8:30 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > No, I was thinking of something along the lines of:
> > INFO: clustering "public.my_c"
> > INFO: complete, was 33%, now 100% clustered
> > The only such measure that we have
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> No, I was thinking of something along the lines of:
> INFO: clustering "public.my_c"
> INFO: complete, was 33%, now 100% clustered
> The only such measure that we have is the correlation, which isn't very
> good anyway, so I'm not sure if that's w
Jim Cox wrote:
On Fri, Oct 10, 2008 at 10:23 AM, Heikki Linnakangas <
[EMAIL PROTECTED]> wrote:
Kevin Grittner wrote:
"Jim Cox" <[EMAIL PROTECTED]> wrote:
if present an INFO message is generated which displays
the schema.tblname just before actual clustering is kicked off (see
example
b
On Fri, Oct 10, 2008 at 10:23 AM, Heikki Linnakangas <
[EMAIL PROTECTED]> wrote:
> Kevin Grittner wrote:
>
>> "Jim Cox" <[EMAIL PROTECTED]> wrote:
>
if present an INFO message is generated which displays
>>> the schema.tblname just before actual clustering is kicked off (see
>>>
>> exampl
Kevin Grittner wrote:
"Jim Cox" <[EMAIL PROTECTED]> wrote:
if present an INFO message is generated which displays
the schema.tblname just before actual clustering is kicked off (see
example
below).
postgres=# CLUSTER VERBOSE ;
INFO: clustering "public.my_b"
INFO: clustering "public.my_c"
>>> "Jim Cox" <[EMAIL PROTECTED]> wrote:
> if present an INFO message is generated which displays
> the schema.tblname just before actual clustering is kicked off (see
example
> below).
> postgres=# CLUSTER VERBOSE ;
> INFO: clustering "public.my_b"
> INFO: clustering "public.my_c"
> INFO: cl
On Thu, Oct 9, 2008 at 9:37 AM, Jim Cox <[EMAIL PROTECTED]> wrote:
> Is anyone working the "CLUSTER: Add VERBOSE option..." TODO item listed
> on the PostgreSQL Wiki? If not, would it be wise for me to use
> VERBOSE handling in an existing command (e.g. VACUUM)
> as a guide while adding VERBOSE to
18 matches
Mail list logo
