On Tue, 2006-06-13 at 15:00 +0200, Martijn van Oosterhout wrote: > What you might be able to do is to reduce its effect. The thing that > occurs to me is to make hint bit changes only mark a page half-dirty. > If the page is evicted because the space is needed in the buffer cache, > it can be just dropped. However, the bgwriter will write it as normal. > Hence, setting hint bits will become a sort of background operation, > done when there's time.
Yes, I think that's a very good idea. What that introduces is the concept of "dirty priority" - i.e. some pages are more important to write out quickly than others. If the bgwriter cleans the higher priority ones first it should do a better job of keeping the bufferpool clean. That needs some work on it before its a fully fledged proposal. > It seems to me that if a large table is loaded in a single transaction, > the check for if the transaction is committed should be cheap because > it's checking the same transaction id over and over. I was considering this the other day. My original idea was to set the xmin to be FrozenTransaction when loading a table with COPY in the same transaction as the one that loaded it but that didn't work because of MVCC violation. If we just set the hint bit to show XMIN_COMMITTED then we need not worry about MVCC violations, since the xmin will still be higher than any pre-existing snapshots. I think Tom had a problem with that because it relied on file truncation on recovery, but I'm not clear on why exactly? -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings