Re: limiting hint bit I/O
От | Robert Haas |
---|---|
Тема | Re: limiting hint bit I/O |
Дата | |
Msg-id | AANLkTi=h5WVRozEBtYh6Ss3qhqUXpkVCLRBZQS5R=Q5_@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: limiting hint bit I/O (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: limiting hint bit I/O
|
Список | pgsql-hackers |
On Fri, Jan 14, 2011 at 1:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Fri, Jan 14, 2011 at 12:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Moreover this whole business of not treating hint-bit setting as >>> a page-dirtying operation is completely experimental/unproven IMO, so it >>> would be better to keep the patch footprint as small as possible. > >> I have some concerns about that proposal, but it might be the right >> way to go. Before we get too far off into the weeds, though, let's >> back up and talk about something more fundamental: this seems to be >> speeding up the first run by 6x at the expense of slowing down many >> subsequent runs by 10-15%. Does that make this whole idea dead on >> arrival? > > 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: