Why are my COMMITs after SELECT-only transactions slow with PostgreSQL? -
i have web app presenting data that's being generated separate process , stored in postgresql, version 8.4. backend writing continuously, majority of views in web app execute nothing read-only select queries.
according new relic python agent, 30% of view processing time spent waiting commits complete, , it's particularly bad in views issued lot of select queries, if didn't modify data.
i expected transaction had been read-only have little work during commit phase. postgres doing during commit on these read-only queries?
i know turn off synchronous_commit
these transactions hide latency view, , don't care durability read-only transaction, don't see why should necessary, , i'm concerned doing might mask deeper misconfiguration.
there various clean operations need done keep database in shape, , many of these done first process stumbles upon opportunity, if process doing select queries.
these clean operations can generate wal records, trigger syncs upon commit. while selects might read-only on user-visible level, behind scenes doing writes.
it should possible detect when of wal operations done in given transaction clean-up operations, , automatically commit asynchronously in cases. no 1 has gotten around implementing feature yet (or cataloging of wal call-sites in category).
Comments
Post a Comment