Re: Dynamic Partitioning using Segment Visibility Maps

From: Gavin Sherry <swm(at)alcove(dot)com(dot)au>
To: Chris Browne <cbbrowne(at)acm(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Dynamic Partitioning using Segment Visibility Maps
Date: 2008-01-09 22:36:43
Message-ID: 20080109223643.GB999@europa.idg.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 09, 2008 at 02:38:21PM -0500, Chris Browne wrote:
> Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> writes:
> > 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.

One of the reasons for using partitions is that the usefulness of
indexes breaks down because of the low cardinality of the indexed
column. Also, the random IO can kill your performance.

In my opinion, CLUSTER (and vacuum, mentioned else where) are not data
management tools.

Thanks,

Gavin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gavin Sherry 2008-01-09 22:48:03 Re: Dynamic Partitioning using Segment Visibility Maps
Previous Message Tom Lane 2008-01-09 21:05:43 Re: tzdata issue on cross-compiled postgresql