On Mon, Oct 13, 2008 at 8:30 AM, Tom Lane
<tgl@sss.pgh.pa.us> wrote:
Heikki Linnakangas <
heikki.linnakangas@enterprisedb.com> 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 worthwhile.
indexscan, ie the number of tuples with CTID lower than the previous
one's. But I'm not sure how useful that number really is. Also it's
not clear how to preserve such functionality if cluster is
re-implemented with a sort.
regards, tom lane
Another version of the patch should be attached, this time counting the number of "inversions" (pairs of tuples in the table that are in the wrong order) as a measure of the "sortedness" of the original data (scanned/live numbers still reported as an indication of the extent to which the table was vacuumed).
N.B. -- I'm not familiar enough with Postgres internals to know if the included inversion_count() method is a valid way to identify inversions.
In any case, example VERBOSE output:
postgres=# CLUSTER public.my_c VERBOSE ;
INFO: clustering "public.my_c"
INFO: complete, 15 tuples scanned, 10 tuples now live, 2 inversions
DETAIL: CPU 0.00s/0.00u sec elapsed 0.00 sec.
CLUSTER
