Re: [HACKERS] Performance problem partially identified

Tom Lane wrote:
>
> It looks to me like something is broken such that bufmgr.c *always*
> thinks that a buffer is dirty (and needs written out) when it is
> released.

That could also explain why the performance increases quite noticeably
even for _select_ queries when you specify "no fsync" for backend.
(I have'nt checked it lately, but it was the case about a year ago)

> Poking around for the cause, I find that heapgettup() calls
> SetBufferCommitInfoNeedsSave() for every single tuple read from the
> table:
...
> I don't understand this code well enough to fix it, but I assert that
> it's broken.

More likely this is a "quick fix - will look at it later" for something
else, praobably an execution path that fails to call
SetBufferCommitInfoNeedsSave() when needed.

Or it can be just code to check if this fixes it which has been
forgotten in.

> Most of these tuples are *not* being modified, and there
> is no reason to have to rewrite the buffer.

It can be quite a lot of work to find all the places that can modify the
tuple, even with some special tools.

Is there any tool that can report writes to areas set read only
(similar to malloc/free debuggers ?)

If there is then we can replace SetBufferCommitInfoNeedsSave()
with a macro that does both SetBufferCommitInfoNeedsSave() and allows
writing, so that we can automate the checking.

-----------------
Hannu