Re: Running a query twice to ensure cached results.

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