Messages in this thread | | | Date | Mon, 19 Sep 2011 07:25:00 -0600 | From | Matthew Wilcox <> | Subject | Re: [HACKERS] Improve lseek scalability v3 |
| |
On Mon, Sep 19, 2011 at 08:31:00AM -0400, Stephen Frost wrote: > * Benjamin LaHaise (bcrl@kvack.org) wrote: > > For such tables, can't Postgres track the size of the file internally? I'm > > assuming it's keeping file descriptors open on the tables it manages, in > > which case when it writes to a file to extend it, the internally stored size > > could be updated. Not making a syscall at all would scale far better than > > even a modified lseek() will perform. > > We'd have to have it in shared memory and have a lock around it, it > wouldn't be cheap at all.
Yep, that makes perfect sense. After all, the kernel does basically the same thing to maintain this information; why should we have userspace duplicating the same infrastructure?
I must admit, I'd never heard of this usage of lseek to get the current size of a file before; I'd assumed everybody used fstat. Given this legitimate reason for a high-frequency calling of lseek, I withdraw my earlier objection to the patch series.
-- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step."
| |