maria-developers team mailing list archive
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:
> 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
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?