2 ms·
Plan caching is different from prepared statements, but yes PG is not as advanced as other commercial databases in execution. Usually the database client driv
by manigandham 7y ago
Plan caching is different from prepared statements, but yes PG is not as advanced as other commercial databases in execution.
Usually the database client drivers will handle this for you. If you're using .NET, the npgsql driver maintains a connection pool and creates prepared statements for each new session. If you have something like PGBouncer in the middle then it gets more complicated.
- SigmundA 7y agoThere is almost no point is using prepared statements in MSSQL anymore, not for a long time. The only benefit comes from not sending the prepared statement over the wire each time and not having to hash it to do a plan lookup. That benefit is so very minor compared to the time taken to parse and plan the statement that almost none uses it, for more details: https://dba.stackexchange.com/questions/129659/what-is-the-sense-and-benefit-of-using-sqlcommand-prepare/129721#129721 https://dba.stackexchange.com/questions/129659/what-is-the-s... In PG its seems to be the only choice and on top of that isn't even shared among connections, this honestly blows my mind and will have to remember if I move anything serious over to PG. I like PG a lot and it does a lot of thing MSSQL doesn't but this is a big missing performance piece.
- manigandham 7y agoI'm very familiar with both (and we use both) but plan caching isn't going to make that much of a difference for many scenarios. PG also has simpler planning than MSSQL anyway. I doubt you'd notice a difference unless you're extremely complex queries or a very high rate of transactions.