Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
> Chris Browne wrote:
>> _On The Other Hand_, there will be attributes that are *NOT* set in a
>> more-or-less chronological order, and Segment Exclusion will be pretty
>> useless for these attributes.
>
> Really? I was hoping that it'd be useful for any data
> with long runs of the same value repeated - regardless of ordering.
>
> My biggest tables are clustered by zip/postal-code -- which means that
> while the City, State, Country attributes aren't monotonically increasing
> or decreasing; they are grouped tightly together. I'd expect all queries
> for San Francisco to be able to come from at most 2 segments; and all queries
> for Texas to be able to come from only a fraction of the whole.
>
>
> If the segment sizes are configurable - I imagine this would even
> be useful for other data - like a people table organized
> by last_name,first_name. "John"'s may be scattered through out
> the table -- but at least the John Smith's would all be on one
> segment, while the Aaron-through-Jim Smith segments might get excluded.
>
> Or am I missing something?
Well, this can head in two directions...
1. Suppose we're not using an "organize in CLUSTER order" approach.
If the data is getting added in roughly "by order of insertion" order,
then there's no reason to expect San Francisco data to be clustered
together.
Ditto for "John Smiths;" we can expect them to be as scattered as
their dates of creation.
1. Suppose we *are* using an "organize in CLUSTER order" approach.
In that case, yes, indeed, you can expect segments to contain specific
ranges of the data.
However, in that case, the ONLY dimension under which the Segment
Exclusion may be expected to be useful is that of the first column of
the index being used. "Smith" should be useful to SE, but not "John,"
because, as a secondary criteria, the first name values will be
scattered across all segments.
--
(reverse (concatenate 'string "ofni.sesabatadxunil" "@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/linuxdistributions.html
PALINDROME spelled backwards is EMORDNILAP.