2011/9/19 Matthew Wilcox <matt...@wil.cx>: > On Mon, Sep 19, 2011 at 08:31:00AM -0400, Stephen Frost wrote: >> * Benjamin LaHaise (b...@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." > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
I really don't understand the approach here. An improvement is an improvement, do we need a use case to add an improvement to the kernel? We are not talking about to add a new syscall or to do an ABI change in this case. So my absolute ack to these patches. Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
