maria-developers team mailing list archive

[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