Re: limiting hint bit I/O
От | Tom Lane |
---|---|
Тема | Re: limiting hint bit I/O |
Дата | |
Msg-id | 8703.1295029005@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: limiting hint bit I/O (Robert Haas <robertmhaas@gmail.com>) |
Список | 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 по дате отправления: