MySQL Connector/ODBC does not support the connection string options POOLING and MAXIMUMPOOLSIZE. These options will be ignored unless the ODBC Driver Manager detects these options and uses them to create a connection pool for the selected driver. This greatly depends on the ODBC Driver Manager.
The recommended way of enabling the pooling is setting the ENV attribute as follows:
SQLSetEnvAttr(henv, SQL_ATTR_CONNECTION_POOLING, (SQLPOINTER)SQL_CP_ONE_PER_DRIVER, 0);
You can search for SQL_ATTR_CONNECTION_POOLING and see how it is used.
Answers to your questions are:
Q1: Is connection pooling enabled in the myodbc connector itself?
A1: No. The connection pooling is the responsibility of the ODBC Driver Manager.
Q2: Or is there any connection pooling dependency on unix-ODBC as well?
A2: Different ODBC Driver Managers implement connection pooling differently, but it is possible to use connection pooling with UnixODBC Driver Manager.
Q3: Is there any way to verify the effect of enabling connection pooling? Are there any tangible tests I can perform to see if the option has taken effect? Is it possible to check the behavior w.r.t. netstat output and seeing the connections between the client and server etc., track their state etc?
A3: The most noticeable effect of the connection pooling is reducing the time required for connecting to MySQL Server. Your program could sequentially do SQLConnect()/SQLDisconnect() in a loop with 1000 repeats. With the connection pooling enabled it should take a lot less time. Also, because the connections are re-used the connection ID will stay the same as in one of previous connects. The application can also check if the pooling is enabled by calling SQLGetEnvAttr(henv, SQL_ATTR_CONNECTION_POOLING, ....);
For UnixODBC the pooling can be enabled through odbcinst.ini file where you specify the configuration option for a specific driver: