I read at several places, including here, that "postgres has a particularly poor C API for communicating type information in prepared statements". It is suggested to use PDO::ATTR_EMULATE_PREPARES as a workaround (PDO being better at that).

I'm not sure of the impact of this in terms of performance (probably moderate, because we don't reuse prepared statements that often), but we should study that approach.

Comments

drewish’s picture

drewish CreditAttribution: drewish commented

subscribing

Damien Tournoud’s picture

Damien Tournoud CreditAttribution: Damien Tournoud commented
Title: PostgreSQL surge #16: Determine if we should use PDO::ATTR_EMULATE_PREPARES » Determine if we should use PDO::ATTR_EMULATE_PREPARES
Issue tags: +PostgreSQL Surge

Properly tag those.

Crell’s picture

Crell CreditAttribution: Crell commented

We're using it for MySQL at present, too at the moment, as prepared statements apparently bypass the query cache. We should probably benchmark it for both systems now that core has been running well with PDO for a while.

Damien Tournoud’s picture

Damien Tournoud CreditAttribution: Damien Tournoud commented
Title: Determine if we should use PDO::ATTR_EMULATE_PREPARES » Determine if we should use PDO::ATTR_EMULATE_PREPARES on PostgreSQL
Josh Waihi’s picture

Josh Waihi CreditAttribution: Josh Waihi commented

subscribing

Josh Waihi’s picture

Josh Waihi CreditAttribution: Josh Waihi commented

Considering the progress we've made thus far with the PostgreSQL driver, what advantages will this have if any? do we need it?

Josh Waihi’s picture

Josh Waihi CreditAttribution: Josh Waihi commented
Status: Active » Postponed (maintainer needs more info)

I'm not sure we need this, unless an argument is provided to put this in, I'll close this issue

Damien Tournoud’s picture

Damien Tournoud CreditAttribution: Damien Tournoud commented
Status: Postponed (maintainer needs more info) » Closed (won't fix)

It doesn't seem to make a lot of difference one way or the other.