"Tom Lane" <[EMAIL PROTECTED]> writes: > "Jignesh K. Shah" <[EMAIL PROTECTED]> writes: >> CLOG data is >> not cached in any PostgreSQL shared memory segments > > The above statement is utterly false, so your trace seems to indicate > something broken. Are you sure these were the only reads of pg_clog > files? Can you extend the tracing to determine which page of the file > got read? I am wondering if your (unspecified) test load was managing > to touch more pages of the clog than there is room for in shared memory.
Didn't we already go through this? He and Simon were pushing to bump up NUM_CLOG_BUFFERS and you were arguing that the test wasn't representative and some other clog.c would have to be reengineered to scale well to larger values. Also it seemed there were only modest improvements from raising the value and there would always be a ceiling to bump into so just raising the number of buffers isn't particularly interesting unless there's some magic numbers we're trying to hit. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
