Re: limiting hint bit I/O - Mailing list pgsql-hackers

From Tom Lane
Subject Re: limiting hint bit I/O
Date
Msg-id 8703.1295029005@sss.pgh.pa.us
Whole thread Raw
In response to Re: limiting hint bit I/O  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Jan 14, 2011 at 1:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Well, it reinforces my opinion that it's experimental ;-). �But "first
>> run" of what, exactly?

> See the test case in my OP.  The "runs" in question are "select sum(1) from s".

>> And are you sure you're taking a wholistic view
>> of the costs/benefits?

> No.

Well, IMO it would be a catastrophic mistake to evaluate a patch like
this on the basis of any single test case, let alone one as simplistic
as that.  I would observe in particular that your test case creates a
table containing only one distinct value of xmin, which means that the
single-transaction cache in transam.c is 100% effective, which doesn't
seem to me to be a very realistic test condition.  I think this is
vastly understating the cost of missing hint bits.

So what it needs now is a lot more testing.  pg_bench might be worth
trying if you want something with minimal development effort, though
I'm not sure if its clog access pattern is particularly realistic
either.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: FOR KEY LOCK foreign keys
Next
From: "Kevin Grittner"
Date:
Subject: Re: limiting hint bit I/O