"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

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

Reply via email to