Comments on: Limiting InnoDB Data Dictionary

By: Vadim

Vadim — Mon, 16 Feb 2009 05:38:40 +0000

2 mysqldba

yes, we will port to XtraDB eventually…

By: wlad

wlad — Fri, 13 Feb 2009 01:53:37 +0000

ANSI does not specify that size_t is equal to unsigned long anywhere. Casting pointer or long to int is commonly considered bad. Casting pointer or size_t to long is exactly as bad, given that a platform/compiler can choose LP or LLP (or ILP or SILP) model for 64 bit handling (http://en.wikipedia.org/wiki/64-bit)

In fact, the whole 64 bit support on Windows in compiler and SDK and reference compiler on this platform (MSVC) has been LLP on 64 bit (long is int is 4 bytes, long long is size_t is 8 bytes) since they started playing with Itanium prototypes, and that is almost a decade ago.

By: Yasufumi

Yasufumi — Fri, 13 Feb 2009 01:21:57 +0000

wlad,

I am conscious of the portability. And I have understood some (ANSI incompatible?) compiler of Windows treat long as 32bit even if in 64bit platforms.

But, I think there are no 64bit Windows users who uses such huge number of tables over 4GB of dictionary cache….

So, it may not so serious restriction, and I have chosen simpleness of patch for now.
In the future, if it becomes serious, we should fix it again.

By: wlad

wlad — Thu, 12 Feb 2009 20:44:35 +0000

Ok, now I see it is ulint *on some places*, but well, it is declared as extern ulong somewhere else..

diff -r 9f28f5888574 sql/ha_innodb.h
— a/sql/ha_innodb.h Mon Feb 02 10:23:55 2009 -0800
+++ b/sql/ha_innodb.h Mon Feb 02 10:27:17 2009 -0800
@@ -234,6 +234,7 @@
extern ulong srv_thread_concurrency;
extern ulong srv_commit_concurrency;
extern ulong srv_flush_log_at_trx_commit;
+extern ulong srv_dict_size_limit;

Still, and the value is limited to ULONG_MAX that is 4GB on Windows 64 bit.

By: Vadim

Vadim — Thu, 12 Feb 2009 20:26:12 +0000

wlad,

it is actuall

+extern ulint srv_dict_size_limit;

and is the same as

extern ulint srv_pool_size;
extern ulint srv_awe_window_size;
extern ulint srv_mem_pool_size;

so I would say srv_dict_size_limit is the same for memory allocation as and innodb buffer pool

By: peter

peter — Thu, 12 Feb 2009 19:11:20 +0000

Venu,

Innodb data dictionary is different. First you can run with single large tablespace and in this case number of open files can be irrelevant. Second if you have very many tables (millions) you may have more of them cached in the innodb data dictionary than have file handler associated with it. Opening/Closing file is relatively fast. The update of Innodb stats (bunch of random dives) is the real cost here.

By: venu

venu — Thu, 12 Feb 2009 17:57:32 +0000

As innodb_open_files exists as max open handles; it could have been nice if it was controlled by innodb_table_open_cache (same as table_[open_]cache); so that it limits based on table count instead of size

By: wlad

wlad — Thu, 12 Feb 2009 16:45:26 +0000

+extern ulong srv_dict_size_limit;

This patch has a problem : innodb_dict_size_limit cannot exceed 4GB on 64 bit Windows. Using variations of long is generally not a good idea – it is the worst datatype when it comes to portability. You need size_t for it or larger (i.e ulonglong).

By: Vadim

Vadim — Thu, 12 Feb 2009 07:36:22 +0000

Shlomi Noach,

We only assign flag “table in use” under table_cache lock, that’s all. All main work is done in InnoDB code. So I do not expect problem with table_cache lock.

By: http://mysqldba.blogspot.com/

http://mysqldba.blogspot.com/ — Thu, 12 Feb 2009 07:01:27 +0000

This patch can certainly come in handy. Will it become apart of XTRADB?