On 03.12.2010 04:54, Tom Lane wrote:
Robert Haas<robertmh...@gmail.com> writes:
I then got to wondering whether we should even go a step further, and
simply decree that a page with only hint bit updates is not dirty and
won't be written, period.
This sort of thing has been discussed before. It seems fairly clear to
me that any of these variations represents a performance tradeoff: some
cases will get better and some will get worse. I think we are not going
to get far unless we can agree on a set of benchmark cases that we'll
use to decide whether the tradeoff is a win or not. How can we arrive
at that?
It's pretty easy to come up with a test case where that would be a win.
I'd like to see some benchmark results of the worst case, to see how
much loss we're talking about at most. Robert described the worst case:
Where it's a problem is
when you have a huge table that you're scanning over and over again,
especially if data in that table was loaded by many different, widely
spaced XIDs that require looking at many different CLOG pages.
I'd like to add to that: "and the table is big enough to not fit in
shared_buffers, but small enough to fit in OS cache".
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
