Hi, Timothy!
Sorry for a late answer :(
On Dec 02, Timothy P Clark wrote:
> Thanks, Sergei.
>
> Unfortunately, the ha_data solution has its own problems with partitioned
> tables--for our storage engine at least. Because there is only one
> TABLE_SHARE for all partitions, any information that needs to be shared
> among all handlers attached to a particular partition (but segregated from
> handlers of other partitions) still has to use the mangled partition file
> name ("blah#P#p1") to differentiate. I suppose we could build an array of
> STORAGE_ENGINE_SHAREs into ha_data on the basis of the partition
> information known to the storage engine. However, we would like our engine
> to be as ignorant of the partitioning scheme as possible (and comments in
> table.h lead me to believe this is also the intended direction for the
> storage engine architecture.) Is there some better way to handle the
> partitioning case?
I couldn't come up with a satisfactory solution :(
In my example storage engine I'm now using this:
typedef struct st_demo_share {
const char *name;
THR_LOCK lock;
uint use_count;
struct st_demo_share *next;
} DEMO_SHARE;
static DEMO_SHARE *find_or_create_share(const char *table_name, TABLE *table)
{
DEMO_SHARE *share;
for (share = (DEMO_SHARE*)table->s->ha_data; share; share = share->next)
if (my_strcasecmp(table_alias_charset, table_name, share->name) == 0)
return share;
share = (DEMO_SHARE*)alloc_root(&table->s->mem_root, sizeof(*share));
bzero(share, sizeof(*share));
share->name = strdup_root(&table->s->mem_root, table_name);
share->next = (DEMO_SHARE*)table->s->ha_data;
table->s->ha_data = share;
return share;
}
which is less code and less memory than the HASH solution, and it does
not use a global mutex.
But I'm not satisfied completely as it still includes a search in the
list of shares (although only on ::open() and only in the list of
partitions of one table). And it still includes a reference counter
(use_count) that should be incremented on ::open and decremented on
::close - DEMO_SHARE does not need to be freed, it is in the TABLE_SHARE
memroot and will go away automatically, but there is no callback to
destroy the THR_LOCK, and I had to manage it with a use_count.
Regards,
Sergei
