Re: [HACKERS] Write Ahead Logging for Hash Indexes
От | Stephen Frost |
---|---|
Тема | Re: [HACKERS] Write Ahead Logging for Hash Indexes |
Дата | |
Msg-id | 20170315131845.GP9812@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] Write Ahead Logging for Hash Indexes (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: [HACKERS] Write Ahead Logging for Hash Indexes
Re: [HACKERS] Write Ahead Logging for Hash Indexes |
Список | pgsql-hackers |
Amit, * Amit Kapila (amit.kapila16@gmail.com) wrote: > On Wed, Mar 15, 2017 at 12:53 AM, Stephen Frost <sfrost@snowman.net> wrote: > > If that's the case then > > this does seem to at least be less of an issue, though I hope we put in > > appropriate comments about it. > > I think we have sufficient comments in code especially on top of > function _hash_alloc_buckets(). I don't see any comments regarding how we have to be sure to handle an out-of-space case properly in the middle of a file because we've made it sparse. I do see that mdwrite() should handle an out-of-disk-space case, though that just makes me wonder what's different here compared to normal relations that we don't have an issue with a sparse WAL'd hash index but we can't handle it if a normal relation is sparse. Additional comments here would be overkill if we think that the lower layers are already all set up to handle such a case properly and we don't have to do anything special, but I had understood that we didn't generally think that sparse files would just work. I'm certainly happy to be wrong there because, if that's the case, it'd be a great way to improve the problems we have returning large chunks of free space in the middle of a relation to the OS, but if there is a real concern here then we need to work out what it is and probably add comments or possibly add code to address whatever it is. Thanks! Stephen
В списке pgsql-hackers по дате отправления: