Re: [PROPOSAL] Shared Ispell dictionaries
От | Arthur Zakirov |
---|---|
Тема | Re: [PROPOSAL] Shared Ispell dictionaries |
Дата | |
Msg-id | 5902bb0c-b3aa-acc4-4324-e33735c4e5a8@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: [PROPOSAL] Shared Ispell dictionaries (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [PROPOSAL] Shared Ispell dictionaries
Re: [PROPOSAL] Shared Ispell dictionaries |
Список | pgsql-hackers |
On 21.02.2019 19:13, Robert Haas wrote: > So I think it's better to have each backend locally make a decision > about when that particular backend no longer needs the dictionary, and > then let the system automatically clean up the ones that are needed by > nobody. Yep, it wouldn't be hard to implement. > Perhaps a better approach still would be to do what Andres proposed > back in March: > > #> Is there any chance we can instead can convert dictionaries into a form > #> we can just mmap() into memory? That'd scale a lot higher and more > #> dynamicallly? > > The current approach inherently involves double-buffering: you've got > the filesystem cache containing the data read from disk, and then the > DSM containing the converted form of the data. Having something that > you could just mmap() would avoid that, plus it would become a lot > less critical to keep the mappings around. You could probably just > have individual queries mmap() it for as long as they need it and then > tear out the mapping when they finish executing; keeping the mappings > across queries likely wouldn't be too important in this case. > > The downside is that you'd probably need to teach resowner.c about > mappings created via mmap() so that you don't leak mappings on an > abort, but that's probably not a crazy difficult problem. It seems to me Tom and Andres also vote for the mmap() approach. I think I need to look closely at the mmap(). I've labeled the patch as 'v13'. -- Arthur Zakirov Postgres Professional: http://www.postgrespro.com Russian Postgres Company
В списке pgsql-hackers по дате отправления: