← Back to team overview

maria-developers team mailing list archive

Re: per-partition attributes in the CREATE TABLE


On Tue, May 11, 2010 at 12:05 PM, Sergei Golubchik <sergii@xxxxxxxxx> wrote:
> Hi,
> we've talked about engine attributes in the CREATE TABLE,
> and that one should be able to specify them per partition as well.
> Now, thinking about it, I'm not quite sure what the semantics shuld be.
> What is your use case ? How do you want them to work ?
> I see different possibilities. Say, there is
>  create table ... (.....) XXX=1
>    partition by list (a)
>    (
>       partition p0 values in (1) YYY=2,
>       partition p1 values in (2)
>    );
> 1. We can say that XXX should be listed in the engine's
> hton->table_options, and YYY - in the hton->partition_options.
> this works fine because the engine can use table_share->option_struct
> and it will contain correct values, independent from whether a table is
> partitioned or not.
> but it will break when partitioning will support different engines
> in different partitions.
> 2. We can say that XXX is partition engine options, and a pluggable
> engine can only see YYY. YYY should come from hton->partition_options,
> and the engine's table level attributes are not applicable.
> The drawback - every engine needs to have special code to take care of
> the partitioned case, and to duplicate all table-level options in the
> partition-level options.
> 3. Same as 2, but YYY can come from either table level or partition
> level arrays. Every engine still needs the special code for partitioned
> case, but does not need to duplicate the table_options array.

Thinking as an end user only, I would vote for a scheme where the
following holds true:

i) Anything that can be specified table level, could also be specified
partition level.

 create table ... (.....) XXX=1
   partition by list (a)
      partition p0 values in (1),
      partition p1 values in (2)


 create table ... (.....)
   partition by list (a)
      partition p0 values in (1) XXX=1,
      partition p1 values in (2) XXX=1

are both possible and equivalent.

ii) anything that can be defined for all partitions, can be instead
defined on the table level part.

Ie, from the above two create statements, I can always choose to write
the former, never forced to repeat XXX=1 for all partitions.

iii) For the problem with different engines per partition, and only
one engine supports XXX=1 I could argue that it is not allowed to
specify it on table level. If all specified engines support XXX=1,
then it is allowed to specify it on table level.

Is this helpful?


email: henrik.ingo@xxxxxxxxxxxxx
tel:   +358-40-5697354
www:   www.avoinelama.fi/~hingo
book:  www.openlife.cc

Follow ups