On Thu, Jul 28, 2011 at 12:53 PM, Josh Berkus <josh@agliodbs.com> wrote:
> Robert,
>
>> If the value is less than v1, put it in a partition called p1.
>> If the value is less than v2, put it in a position called p2.
>> <repeat ad nauseum, and then, optionally:>
>> If the value is not less than any of the above, put it in a partition
>> called poverflow.
> Sure. I'm just restarting the discussion from the point of "what's the
> very simplest implementation of partitioning we could create and still
> be useful?"
> Second, the key-based partitioning I described would actually be
> preferred to what you describe by a lot of users I know, because it's
> even simpler than what you propose, which means less contract DBA work
> they have to pay for to set it up.
But part of the desire for "simple partitioning" is to make sure the
query planner and execution knows about partitions, can do exclude
unnecessary partitions from queries. If partion knowledge doesn't
help the query plans, its not much use excpt to reduce table size,
which isn't a hard task with the current inheritance options.
But if the "partition" selection is an opaque "simple key" type
function, you haven't given the planner/executor anything better to be
able to pick partitions for queries, unless the query is an exact "key
=" type of operation.
So I'm failing to see the benefit of that "key based" partitioning,
even if that key-based function was something like date_trunc on a
timestamp...
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
