Re: Turning off HOT/Cleanup sometimes
| От | Peter Eisentraut |
|---|---|
| Тема | Re: Turning off HOT/Cleanup sometimes |
| Дата | |
| Msg-id | 5537E187.8010005@gmx.net обсуждение исходный текст |
| Ответ на | Re: Turning off HOT/Cleanup sometimes (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
| Список | pgsql-hackers |
On 4/22/15 11:37 AM, Jim Nasby wrote: > On 4/21/15 4:07 PM, Peter Eisentraut wrote: >> On 4/21/15 4:45 PM, Jim Nasby wrote: >> In order for a background worker to keep up with some of the workloads >> that have been presented as counterexamples, you'd need multiple >> background workers operating in parallel and preferring to work on >> certain parts of a table. That would require a lot more sophisticated >> job management than we currently have for, say, autovacuum. > > My thought was that the foreground queries would send page IDs to the > bgworker via a shmq. If the queries have to do much waiting at all on IO > then I'd expect the bgworker to be able to keep pace with a bunch of > them since it's just grabbing buffers that are already in the pool (and > only those in the pool; it wouldn't make sense for it to pull it back > from the kernel, let alone disk). > > We'd need to code this so that if a queue fills up the query doesn't > block; we just skip that opportunity to prune. I think that'd be fine. I think a "to-clean-up map" would work better. But basically we need a way to remember where to clean up later if we're not going to do it in the foreground.
В списке pgsql-hackers по дате отправления: