I saw you asked about prepared statement caching in a previous post in the context of entity/query caching. I wanted to make sure that you realize that prepared statement caching has nothing to do with caching query results, but rather caching the parsed parameterized query within the driver (and potentially, the query plan itself, if supported by your database) itself.
Generally, if you are caching the results of queries, then caching prepared statements becomes less important as consequence of the mere fact that these prepared statements will be used less frequently. In the end, it all depends on your use case, how much heap you have, and how you want to prioritize your data caching.
To enable prepared statement caching, just set the cache size:
We have not enabled query cache for all queries. So the others will benefit with prepared_statement_cache right?
preparedStatementCacheQueries settings for driver does the same as prepared-statement-cache-size settings in WildFly datasource?
Yes - though the cost of preparing a statement is not terribly significant compared to the cost of performing the query itself - so don't expect too much.
The prepared-statement-cache-size attribute is used to perform prepared statement caching within IronJacamar's generic DataSource implementation.
If your vendor's XADataSource implementation already implements prepared statement caching logic, then I would suggest using that instead, as some databases will use this configuration to additionally cache query plans within the database itself.