tag:blogger.com,1999:blog-20038672.post5569860806410993257..comments2024-03-28T00:58:29.187-04:00Comments on Robert Haas: Linux lseek scalabilityRobert Haashttp://www.blogger.com/profile/08393677427643988650noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-20038672.post-20560796000161270422012-11-10T14:10:53.012-05:002012-11-10T14:10:53.012-05:00Why don't you set a flag in shared memory when...Why don't you set a flag in shared memory when a file is extended that the other backends can check to see if they need to call lseek? Firing an "extra" system call on every query is lunacy.Anonymoushttps://www.blogger.com/profile/09118533271230602332noreply@blogger.comtag:blogger.com,1999:blog-20038672.post-87916047735088973962012-05-23T22:53:09.419-04:002012-05-23T22:53:09.419-04:00Robert
Any updates on you testing this on FreeBSD...Robert<br /><br />Any updates on you testing this on FreeBSD?Jacobhttp://example.comnoreply@blogger.comtag:blogger.com,1999:blog-20038672.post-33405607266177642682011-11-15T12:50:35.846-05:002011-11-15T12:50:35.846-05:00I did test fstat(). At very high client counts, f...I did test fstat(). At very high client counts, fstat() was a huge win because it doesn't lock the inode mutex, even in existing Linux releases. However, under ordinary circumstances, it's noticeably slower than lseek, probably because it copies more data from kernel space to user space. So if we went with fstat() it would really be just a hack to work around a kernel issue that only exists on Linux and only people with very large machines will notice, at the expense of everyone else.Robert Haashttps://www.blogger.com/profile/08393677427643988650noreply@blogger.comtag:blogger.com,1999:blog-20038672.post-16139087494013468762011-11-15T12:37:31.207-05:002011-11-15T12:37:31.207-05:00I'm sure the reasoning is sound but is there a...I'm sure the reasoning is sound but is there any reason why stat, fstat and/or lstat aren't being used to get file length information? Do they carry extra overhead that the seek calls don't?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20038672.post-83946223788443304172011-11-15T08:22:33.530-05:002011-11-15T08:22:33.530-05:00@maxmim: Probably not. If we look at the length of...@maxmim: Probably not. If we look at the length of the development cycles of 9.0 and 9.1 it will be out some time late summer or early autumn.Andreas Karlssonnoreply@blogger.comtag:blogger.com,1999:blog-20038672.post-88308685144329681152011-11-15T07:04:31.878-05:002011-11-15T07:04:31.878-05:00There's another very interesting change in Lin...There's another very interesting change in Linux kernel 3.2 that affects PostgreSQL. The I/O-less dirty throttling patches went in: https://lwn.net/Articles/456904/<br /><br />This complements the dynamic writeback throttling patches that were merged in 3.1: https://lwn.net/Articles/405076/<br /><br />As far as I can tell, these together should fix the thrashing behavior when the kernel dirty memory limit is exceeded, which is experienced on write-bound servers, particularly during checkpoints.Marti Raudseppnoreply@blogger.comtag:blogger.com,1999:blog-20038672.post-1184476951850607022011-11-14T17:54:06.442-05:002011-11-14T17:54:06.442-05:00I do have one question not related to this post: W...I do have one question not related to this post: Will PostgreSQL 9.2 be ready before 2012-05-08 which is official release date of fedora 17??? Just asking. I didn't want to ask in mailing lists.Anonymousnoreply@blogger.com