Re: Weird failure with latches in curculio on v15
От | Andres Freund |
---|---|
Тема | Re: Weird failure with latches in curculio on v15 |
Дата | |
Msg-id | 20230206000750.ohqjmbfo3trtwvhc@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Weird failure with latches in curculio on v15 (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: Weird failure with latches in curculio on v15
|
Список | pgsql-hackers |
Hi, On 2023-02-05 15:57:47 -0800, Nathan Bossart wrote: > > For the segment files, we'd likely need a parameter to indicate whether > > the restore is random or not. > > Wouldn't this approach still require each module to handle restoring ahead > of time? Yes, to some degree at least. I was just describing a few pretty obvious improvements. The core code can make that a lot easier though. The problem of where to store such files can be provided by core code (presumably a separate directory). A GUC for aggressiveness can be provided. Etc. > I agree that the shell overhead isn't the main performance issue, > but it's unclear to me how much of this should be baked into > PostgreSQL. I don't know fully either. But just reimplementing all of it in different modules doesn't seem like a sane approach either. A lot of it is policy that we need to solve once, centrally. > I mean, we could introduce a GUC that tells us how far ahead to > restore and have a background worker (or multiple background workers) > asynchronously pull files into a staging directory via the callbacks. > Is that the sort of scope you are envisioning? Closer, at least. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: