| From: | Stephen Frost <sfrost(at)snowman(dot)net> |
|---|---|
| To: | Benjamin LaHaise <bcrl(at)kvack(dot)org> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Matthew Wilcox <matthew(at)wil(dot)cx>, Andi Kleen <andi(at)firstfloor(dot)org>, viro(at)zeniv(dot)linux(dot)org(dot)uk, linux-fsdevel(at)vger(dot)kernel(dot)org, linux-kernel(at)vger(dot)kernel(dot)org, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Improve lseek scalability v3 |
| Date: | 2011-09-19 12:31:00 |
| Message-ID: | 20110919123100.GJ12765@tamriel.snowman.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
* Benjamin LaHaise (bcrl(at)kvack(dot)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.
Thanks,
Stephen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matthew Wilcox | 2011-09-19 13:25:00 | Re: Improve lseek scalability v3 |
| Previous Message | Thom Brown | 2011-09-19 12:27:59 | Re: CUDA Sorting |