maria-developers team mailing list archive

[kentoku <kentokushiba@xxxxxxxxx>]

Hi, Sergei!

My use case is 1.

----- my use case start -----

Currently,
Spider and Vertical Partitioning engine can use
table level "connection", table level "comment",
partition level "comment" and sub-partition level "comment"
for engine options.
This options have following priority.
 1. sub-partition level "comment"
 2. partition level "comment"
 3. table level "comment"
 4. table level "connection"

If you create a table using following SQL,
  CREATE TABLE tbl_a
  (.....)
  ENGINE=spider
  COMMENT='database "auto_test_remote2", table "ta_r3"'
  CONNECTION='socket "mysql_1.sock", host "localhost"'
  PARTITION BY KEY(a) (
    PARTITION pt1 COMMENT='database "auto_test_remote", table "ta_r2"',
    PARTITION pt2 COMMENT='socket "mysql_2.sock"'
  );

pt1 options are
  database "auto_test_remote"
  table "ta_r2"
  socket "mysql_1.sock"
  host "localhost"

and

pt2 options are
  database "auto_test_remote2"
  table "ta_r3"
  socket "mysql_2.sock"
  host "localhost"

----- my use case end -----

I think per-partition options should better to work like this.
If per-partition options works like this, every engine don't need the
special code for partitioned case.

Additionally,
for supporting different engines in different partitions,
table options should better to be added engine names like
global/session parameters for avoiding conflicting option names.

----- example start -----

If you create a table using following SQL,
  CREATE TABLE tbl_a
  (.....)
  innodb_XXX=1 pbxt_XXX=2
  PARTITION BY KEY(a) (
    PARTITION pt1 ENGINE=innodb innodb_YYY=3,
    PARTITION pt2 ENGINE=pbxt pbxt_ZZZ=4
  );

pt1 options are
  innodb_XXX=1
  innodb_YYY=3

and

pt2 options are
  pbxt_XXX=2
  pbxt_ZZZ=4

----- example end -----

What do you think about my opinion?

Thanks,
Kentoku


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