Re: Early hint bit setting
От | Robert Haas |
---|---|
Тема | Re: Early hint bit setting |
Дата | |
Msg-id | CA+TgmoaMLYg43RugcQ52f6gkURQ+JTnoGP-kGcZW907KZDYT_Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Early hint bit setting (Jim Nasby <jim@nasby.net>) |
Список | pgsql-hackers |
On Wed, Jun 6, 2012 at 6:41 PM, Jim Nasby <jim@nasby.net> wrote: > Except that's only true when there are no other transactions running. That's > been one of the big sticking points about trying to proactively set hint > bits; in a real system you're not going to gain very much unless you wait a > while before setting them. No, the committed hint bit just means that the transaction is committed. You don't have to wait for it to be all-visible. I think my biggest concern about this is that it inevitably relies on some assumption about how much latency there will be before the client sends the next request. That strikes me as impossible to tune. On system A, connected to the Internet via an overloaded 56k modem link, you can get away with doing a huge amount of fiddling around while waiting for the next request. But on system B, which uses 10GE or Infiniband or local sockets, the acceptable latency will be much less.Even given identical hardware, scheduler behavior maymatter quite a lot - rumor has it that FreeBSD's scheduling latency may be significantly less than on Linux, although I have not verified it and rumor may lie. But the point is that whether or not this works out to a win on any given system seems like it will depend on an awful lot of stuff that we can't know or control. I would be more inclined to look at trying to make this happen in a background process, although that's not without its own challenges. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: