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

Popular posts from this blog

css - Which browser returns the correct result for getBoundingClientRect of an SVG element? -

gcc - Calling fftR4() in c from assembly -

Function that returns a formatted array in VBA -