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@askmonty.org>:
Hi!
"Sergei" == Sergei Golubchik <sergii@pisem.net> 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