ext/pgsql: add meta_cache per-link metadata caching

[arshidkv12]

• Introduce per-connection meta_cache HashTable in pgsql_link_handle
• Cache results of php_pgsql_meta_data() to avoid repeated catalog queries
• Add lookup before executing PQexec() for faster metadata access
• Initialize meta_cache lazily per connection
• Properly destroy meta_cache on connection free and query mutations
• Clear meta_cache on pg_query/pg_delete to avoid stale schema data
• Add NULL-safe checks for link->meta_cache usage

Improves performance by reducing repeated queries.

[devnexen]

I may have a look later but one large thing I notice is the conflict of interest between persistent connections and request scoped caching. There is probably more to it ..

[arshidkv12]

I need to check as follows. Is that correct?

if (!link->persistent && link->meta_cache) {
    // check cache
}
if (!link->persistent && !link->meta_cache) {
    // allocate cache
} 

[devnexen]

FETCH_DEFAULT_LINK_NO_WARNING() in php_pgsql_meta_data is wrong. The function gets PGconn *pg_link but the cache is looked up against the default link. Those don't match with multiple connections, and OO callers (no default link set) get no caching at all. The pgsql_link_handle * needs to be plumbed through.

[arshidkv12]

Thank you. How can I obtain a pgsql_link_handle *link from a PGconn *pgsql? I believe we cannot replace pgsql_link_handle with PGconn, as it would break the API. How can this be resolved?

[devnexen]

You can't ; plumb the handle through instead. The usual way is to keep the existing PHP_PGSQL_API symbol for ABI and introduce an internal variant taking the link directly. In-tree callers all have it on hand.

[arshidkv12]

Thank you

[devnexen]

Invalidation is incomplete. Wiping on pg_query() only — pg_query_params, pg_execute, pg_prepare, and the pg_send_* family all leave stale entries

[devnexen]

This is pretty repetitive. Could be a helper.

[devnexen]

You really do need to focus on solving design flaws I mentioned earlier. Even then, there might be other issues when I do a 2nd pass.

[arshidkv12]

You really do need to focus on solving design flaws I mentioned earlier. Even then, there might be other issues when I do a 2nd pass.

We could store a direct PGconn > pgsql_link mapping using a HashTable for O(1) lookup:

zend_hash_index_update_ptr(&PGG(conn_to_link), (zend_ulong) pg_conn, link);
link = zend_hash_index_find_ptr(&PGG(conn_to_link), (zend_ulong) pg_conn);

This avoids repeated lookups or iteration. What do you think?

[devnexen]

Rather not, that adds another structure with its own lifetime concerns (insert/remove on connect/close, persistent vs request) just to work around the first one. The handle is already reachable without a side map. Worth a look at how other helpers in the file get it passed in. Should be enough for your agent to get started.

[devnexen]

I do not think it s going to cut it, I'd suggest to put it in draft mode and going through the eviction part, the cache design and so on ... Cheers.

[arshidkv12]

Thank you

[devnexen]

I do not think you re extremely far behind neither but once you re done, there is need for tests too. Good luck